Why dynamic languages for ActiveRecord..?

[ypomonh]

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..?

 

[David A. Black]

Hi --

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

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

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

--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
See http://www.rubypal.com for more info!

 

[Phlip]

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.

 

[Phlip]

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.

 

[David A. Black]

Hi --

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."

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

--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
See http://www.rubypal.com for more info!

 

[Robert Dober]

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

 

[Phlip]

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!

 

[JeremyWoertink]

haha, nice! Especially the name.

require 'evil'

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

 

[Phlip]

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. (-;

 

[M. Edward (Ed) Borasky]

"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. (-;

Would that be a "Yes bot"?

<ducking>