Kero <kero / chello.single-dot.nl> writes:

>>> > Why is it that people have the idea the ojects are
>>> difficult for 
>>> > programming newbies?
>>> 
>>> Because many ppl learned OO *after* learning some
>>> imperative language?
>>> Which means they had to adapt their mind, instead of
>>> using an unspoiled
>>> brain.
>>
>> I always read this on this message board, but must
>> confess that being a programming and Ruby beginner,
>> i'm still not 100% regarding the true meaning of OO.
>
> OO provides a means of abstraction based on inheritance of
> functionality. Sometimes you change the implementation, sometimes you
> add functionality in a subclass.
>
> The assumption is that you will have many alike objects that will do the
> same or similar things.
>
> [I'm sure ppl have other definitions or even plainly disagree with what
> I wrote down here, I'm perfectly fine with that, see last remark of this
> posting, too!]

I think your definition should at least be extended. :-) The thing
that makes OO really "object-oriented" is the encapsulation of data.
The core of OO is to have (mostly) class-specific methods that handle
the encapsulated data.  If you need to fud with the data of other
objects directly, you're not following OO (cf. Demeter's Law).

However, this is something imperative programmers like to do when they
are introduced to OO.  It is something to be "unlearned" to write good
OO code.  In fact, a good OO program doesn't look any imperative at
all (of course, the implementation of some algorithms still requires
imperative code, but the biggest part should look very different; and
this is often confusing newbies trying to read an OO program: Where do
I begin?).  I think "A litte Java, a few patterns" is an excellent
book to show how far you can go with OO (it also shows the problems of
Java OO).  I think someone did a Ruby version of that book, but I
can't find it right now.

> If the abstraction is not available in the language, you can still
> program OO, but it will be more verbose. We were taught to program in
> Abstract Data Types in Pascal (back in 1992), basically put a record and
> the functions that work on it in one file. a subclass would be
>    `cp from.p to.p`
> and adding the functionality. more verbose, maintenance nightmare.

The alternative would be to make the "subclass" be a record which has
the "class" as a member.  This will make you write lots of delegators,
but that's probably still better than real code duplication.

>> How Ruby OO is different from any other OO?
>
> If it is different, knowing OO does not help when learning Ruby :)

I think it is true that when you, say, only know Java, you need to
pickup a fair lot of new concepts first.  (Classes as true objects,
singleton methods, real dynamic typing, no interfaces, blocks, etc.)

Of course, it's a lot easier than coming from an imperative language,
though.

> And maybe it is. Since everything is an Object in Ruby and
> Smalltalk, this has influence on how libraries _can_ be built (and
> are).

Yeah, the *real* difference is that Ruby is one of the purest
languages with respect to OO.  This can be something like "culture
shock", I imagine.  (Still not as bad as people coming to Smalltalk
learn that the control structures are methods too.)

> Kero
-- 
Christian Neukirchen  <chneukirchen / gmail.com>  http://chneukirchen.org