Why dynamic languages for ActiveRecord..?

Ruby
1

I¢m having problems understanding why people prefer to implement the
ActiveRecord pattern in dynamic languages. Of course it is very
convenient if you don¢t have to worry about what type is your column,
but dynamic languages are more than that.

Do åval, higher-order functions, runtime alteration of object, closures,
etc. matter in the implementation of the ActiveRecord pattern…?

2

class YourTable < ActiveRecord::Base
end

instance = YourTable.find(:first)
instance.column_one
instance.column_two

instance.something = true
instance.save!

I’ve never seen a cleaner ActiveRecord implementation than in Ruby. You
don’t have to write a lick of code past a class definition to get a
fully
featured look into your database table.

Compare the above to what it take in Java with Hibernate, and it’s
pretty
obvious why such things are done in dynamic languages.

Jason

3

ypomonh wrote:

I’m having problems understanding why people prefer to implement the
ActiveRecord pattern in dynamic languages. Of course it is very
convenient if you don’t have to worry about what type is your column,
but dynamic languages are more than that.

You are describing a “soft” language, such as Perl, JavaScript, or
some aspects of BASIC. A variable can change its type based on its
environment.

Ruby is a strongly, dynamically typed language. Strong because nothing
ever changes its type, and dynamic because you can add features to

Do åval, higher-order functions, runtime alteration of object, closures,
etc. matter in the implementation of the ActiveRecord pattern…?

You are asking how a “Domain Specific Language” can integrate with a
host language of a different type. Ruby is procedural, and SQL is
declarative. The answer is you use the host language’s features to
write a declarative DSL. ‘select foo from bar’ becomes
Bar.find(:select => :foo)

Both expressions are declarative, but the Ruby one can now enjoy the
benefits of the rest of Ruby.

4

Ruby is a strongly, dynamically typed language. Strong because nothing
ever changes its type, and dynamic because you can add features to

existing code, including getters and setters that make types appear
dynamic.

5

Hi –

On Wed, 26 Sep 2007, Phlip wrote:

Ruby is a strongly, dynamically typed language. Strong because nothing
ever changes its type, and dynamic because you can add features to

I think there’s part of a sentence missing there. I wanted to comment
on the first part anyway :slight_smile:

I’d say that the type of a Ruby object can change, but its class
cannot. That’s based on an understanding of the object’s type as a
kind of runtime snapshot of what the object can do and what messages
it understands.

This framing of it is, I believe, behind the deprecation of
Kernel#type (which I think only existed in the first place because
“class” was impossible to parse as a method name in some early Ruby
versions).

I find it a useful distinction, in part because otherwise one has to
come up with yet another term to refer to the thing that can change.

David

6

David A. Black wrote:

I’d say that the type of a Ruby object can change, but its class
cannot. That’s based on an understanding of the object’s type as a
kind of runtime snapshot of what the object can do and what messages
it understands.

The inspiration there is Smalltalk, which is similarly strongly typed.

One common confusion among newbs is that weak typing == dynamic typing.

7

On 9/25/07, Phlip [email protected] wrote:

David A. Black wrote:

I’d say that the type of a Ruby object can change, but its class
cannot. That’s based on an understanding of the object’s type as a
kind of runtime snapshot of what the object can do and what messages
it understands.

The inspiration there is Smalltalk, which is similarly strongly typed.
I would not agree with this statement. Smalltalk strongly typed???
Furthermore there is Object>>becomes: (or was it a different class?)
which lets an object change its class too, so that makes a big
difference to Ruby.
BTW I had love to have Object#becomes in Ruby :)))

Cheers
Robert

8

Hi –

On Wed, 26 Sep 2007, Phlip wrote:

David A. Black wrote:

I’d say that the type of a Ruby object can change, but its class
cannot. That’s based on an understanding of the object’s type as a
kind of runtime snapshot of what the object can do and what messages
it understands.

The inspiration there is Smalltalk, which is similarly strongly typed.

That’s the proximate inspiration, though I always remember Matz
summing it up at RubyConf 2002 (I think): “Ruby is dynamic, like human
nature.” :slight_smile:

One common confusion among newbs is that weak typing == dynamic typing.

In the long run, the notion of type in Ruby is tautological: an object
is of type “The type which is the type of objects that are of this
object’s type.” That may be why “type” sometimes gravitates toward
being a synonym for “class” (along with the historical accident of
Kernel#type), though I think having a separate term for the changable
part is useful, and also makes sense of phrases like “duck typing”.

David

9

Robert D. wrote:

The inspiration there is Smalltalk, which is similarly strongly typed.

I would not agree with this statement. Smalltalk strongly typed???

I learned that from this guy:

http://c2.com/cgi/wiki?JohnSarkela

You are free to argue with him, but I ain’t gonna!

10

haha, nice! Especially the name.

11

On 9/25/07, Robert D. [email protected] wrote:

I would not agree with this statement. Smalltalk strongly typed???
other people.
– Katharine Hepburn

require ‘evil’

http://eigenclass.org/hiki.rb?evil.rb+dl+and+unfreeze

12

ypomonh wrote:

Philip, let me see if I got it straight:

Ruby seems more well suited (eg. from Java) for implementing the
ActiveRecord pattern, because its dynamic features make it easy/easier
to implement (pretty much) any pattern. There is no inherent connection
between the language and this specific pattern.

Am I correct?

“Yes and…”

That’s consultant speak. We practice not saying “No but”. (-;

The narrowest detail here is Java does not permit def my_column=, so its
code will always look ugly and resist elegance, especially when doing
Active
Record.

In general, Ruby is more suited than Java for anything in Java’s space,
except the crackerjack marketing to “enterprises”. We are working on a
bot
for that. (-;

13

Phlip wrote:

Ruby is a strongly, dynamically typed language. Strong because nothing
ever changes its type, and dynamic because you can add features to

existing code, including getters and setters that make types appear dynamic.

Philip, let me see if I got it straight:

Ruby seems more well suited (eg. from Java) for implementing the
ActiveRecord pattern, because its dynamic features make it easy/easier
to implement (pretty much) any pattern. There is no inherent connection
between the language and this specific pattern.

Am I correct?

14

Phlip wrote:

bot for that. (-;
Would that be a “Yes bot”?