[ruby-talk:19524] order and freedom in Ruby (was: Re: Re: the way class variables work)

Hello --

On Sat, 11 Aug 2001, Chris Uzdavinis wrote:

> David Alan Black <[e-mail]> writes:
>
> > Hello --
> >
> > I've been puzzling over Ruby's treatment of class variables -- not so
> > much the "what" as the "why".
>
> You bring up some good questions, which leads to only more questions.

So do you, and so do they :-)

Quoting back selectively:

> What does it really mean to be an instance of a class when methods can
> be dynamically created?
...
> Given a class, there is no guarnatee that any objects instantiated
> from it still share its interface at all.  It's wishful thinking to
> assume two objects with the same "base class" have anything in common
> whatsoever, aside from that base class.
...
> Question: Does inheritance honestly have any significant meaning in
>           Ruby?
>
...
> this is an absolutely false claim in Ruby:
>
>     "x1 and x2 were both created from class X, therefore x1 and x2
...
> Traditional "is-a" object oriented theory does not apply to Ruby.
> Ruby is about interfaces, not about types, not about hierarchies.

What I find fascinating about this area of reflection and discussion
(of which there's been a good bit lately on irc and elsewhere) is the
question of how it relates to the order within which Ruby's freedom
operates.  In fact, if I may meta-ize that last quoted sentence, I see
three ways of looking at Ruby itself:

Way 1: Ruby presents different interfaces to the programmer.  You can,
if you choose and/or need to, use Ruby to handle your traditionally OO
projects.  Or you can use Ruby pseudo-procedurally.  Or you can tap
into Ruby's powers in the area of dynamic method creation and related
things.

Way 2: Ruby is a certain type of programming language.

Way 3: Ruby's range of powers is arranged in a hierarchy.  Writing
procedural code in Ruby is infantile.  Writing traditional OO
programs, where a Horse "is a" Animal, is adolescent.  Breaking with
these things signifies Ruby adulthood.

In my view, neither Way 2 nor Way 3 gets us very far.  I tend to find
Way 1 the most meaningful (which meshes nicely, in a meta kind of way,
with your sentence :-).

Maybe it's because I write programs in situations where there really
isn't any chance that someone else is going to add methods to my
objects... but I have never found any reason not to use a traditional
OO style in Ruby, when it suits a project.  And when I write
procedural, shell-scriptish things in Ruby, they work.  (Which sounds
kind of trivial but is very much at the heart of things.)

It's interesting in this connection that you say, "It's wishful
thinking to assume two objects with the same "base class" have
anything in common whatsoever, aside from that base class."  I
completely understand what you mean, in terms of Ruby's programming
facilities.  But it has a sort of ominous sound, as if the code might
change itself when your back is turned.  I wonder if that's actually
true in some situations :-)  And whether, in other situations, it's a
matter of decision-making, rather than wishful thinking.

There is nothing about Ruby that I do not want to understand and
possibly use.  I am *not* making some kind of case for pretending that
Ruby is a traditional OO language.  I'm just working toward a view
that comprises the various, ummmm, facets of Ruby.  (Or interfacets.)


David

-- 
David Alan Black
home: [e-mail]
work: [e-mail]
Web:  http://pirate.shu.edu/~blackdav