Hi --

On Wed, 12 Feb 2003, Chris Pine wrote:

> ----- Original Message -----
> From: <dblack / candle.superlink.net>
>
> But a further question is: how fundamental is the inheritance hierarchy
> to designing programs in Ruby, given the non-kind_of? underpinnings of
> Ruby objects (i.e., their dynanism and "in-the-moment" behavior)?
> ----------------------------
>
> I'm not sure I understand what you mean.  `kind_of?' determines what methods
> an object has, even if those methods are dynamically added, or singleton
> methods, or whatever.  Without `kind_of?' (meaning the inheritance heirarchy
> it represents), Ruby objects would become C structures!

I'm not sure I understand that last point, but in any case,
obj.kind_of?(Mod) determines only whether Mod occurs among obj's
ancestral classes and/or modules.  It doesn't tell you anything about
what the object actually does (i.e., what messages it responds to, and
how).

  irb(main):002:0> a = "abc"
  "abc"
  irb(main):003:0> def a.talk; puts "I'm a talking String!"; end
  nil
  irb(main):004:0> a.kind_of?(String)
  true
  irb(main):005:0> b = "def"
  "def"
  irb(main):006:0> b.kind_of?(String)
  true
  irb(main):007:0> a.talk
  I'm a talking String!
  nil
  irb(main):008:0> b.talk
  NameError: undefined method `talk' for "def":String
	  from (irb):8

It's possible to write Ruby programs that sort of shadow what you'd
have to do in Ruby if objects didn't have this dynamism.  But they do
:-)

> In that quote, matz seemed to be against over-using inheritance.  And I
> think that's similar to my original point:  don't subclass from a class
> (base class or not) unless you want to use the subclass in place of the
> class.  Don't inherit from Array unless you are making a new kind_of? Array;
> a class where you *will* want to use every method Array has, and (perhaps)
> then some.

I interpret Matz's words very differently.  I think what he was saying
is that inheritance, in Ruby, can be viewed as not so much a
hierarchical thing but a kind of borrowing of functionality.  In any
case, it's the object, at runtime, that either can or cannot do
things.  It's true that someone can send an irrelevant message to a
Roster object.  But it's also true that, if someone wants to step
outside the documented interface and mess around with Roster objects,
that person can do:

  r = Roster.new
  def r.rogue_method .... end


David

-- 
David Alan Black
home: dblack / candle.superlink.net
work: blackdav / shu.edu
Web:  http://pirate.shu.edu/~blackdav