On Fri, Jul 29, 2005 at 08:45:47PM +0900, Tristan Knowles wrote:
> 
> --- Kero <kero / chello.single-dot.nl> wrote:
> > > 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.

My take (but since I was programming long before I knew OO, this might
not be at all what you want to know):

"pure" Object Oriented programming languages assume that all
data is stored in an object, and all behaviour is somehow implemented 
by calling methods on (or sending messages to, call it what you want)
an object. 

an object in its basic form is then just a set of data (properties)
and methods. It's generally considered useful to keep the data internal
to the object, and only allow "outside" access to that data via methods.

What makes OO interesting is polymorphism: 2 objects that somehow support
a shared interface (one or more method signatures) can be interchanged
in the code to allow different behaviour by only passing a different
object. The code interfacing with that object does not need to know what
the difference is.

A very simple example:

class Printer
 def initialize( stream )
    @stream = stream
 end

 def print_content()
    puts @stream.read    
# note that puts is a method of the Printer object, since puts is
# pulled in from Kernel via Object
 end

# ... do more interesting things here
end

This code can print from any object as long as that object implements
a read() method.

OO *can* also help software design, as it tends to lead to fairly
natural divisions in responsibility - in the Printer example above, I
could have added methods for retrieving data via HTTP, or shared memory
etc, but since those actions don't have anything to do with the printing
action, they're better implemented somewhere else (in the stream object,
in this case). But OO design is no guarantee of good design, and it
takes a lot of time to learn how to do OO "right" in complex systems.

> How Ruby OO is different from any other OO?

* Ruby is just another interpretation of OO - most languages differ in
their implementation.

* Alhough in ruby's, everything is an object, the syntax has a lot of
shortcuts for constructs that would be annoying to type and difficult
to read in a "pure" OO way.

* In Ruby, the only way to access properties from outside the object is
via methods. A lot of other languages allow methods of some object to 
directly access (some) properties of another object.

* Ruby does not have an explicit way of stating interfaces: all objects
that have a useful implementation of the required methods can be used
polymorphically, unless you explicitly check for "type". Most dynamic
languages I know that support OO techniques do the same. Most statically
typed languages require you to explicitly state the interface one way
or the other (in java's you can use the interface keyword, in C++ you need 
multiple inheritance).

* Explicitly supporting modules / mixins is fairly unique (as far as I
know)

* Ruby is flexible in modifying objects / classes / inheritance *and* it
makes that flexibility explicit. 

* Like most languages, Ruby has a class-based object system (though more
flexible than most, see above). For another interesting implementation of
OO, see the protype-based javascript / ecmascript language (it's more
flexible in some ways, but you need to overcome the annoyingly C-like syntax)

Joost.