From: Charles Hixson <charlesh@...>
Date: 2001-09-29T00:49:45+09:00
Subject: [ruby-talk:21807] Re: inheritance Surprise!

ts wrote:

 >>>>>> "F" == Florian G Pflug <fgp@phlo.org> writes:
 >>>>>>
 >
 > F> Maybe the standard library should (in the long term) be
 > converted to avoid F> such problems by either using
 > self.class.new in such cases.
 >
 > If you do this you enter a new rule. This new rule will
 > conflict with an existent rule.
 >
 > See what matz has said about this rule [ruby-talk:11575]
 >
 >
 > Guy Decoux
 >
Interesting.  Taking that description of "max" and the earlier 
discussion of "responds_to?" inspires me to consider a different 
function, I'd prefer calling it union rather than +, that 
responds to any call that any of it's arguments could respond to 
(left hand first, following an old Python rule).  I'm not sure 
whether this should create a type (in violation of Ruby's 
assumption of single inheritance) or just create unique instances.

What is the benefit of a type?  Is there any reason that a Class 
shouldn't be constructed from a prototype object?  Can it be?  I 
have a vague memory that says that it can, but haven't been able 
to track it down.  But regardless, should it be possible?  This 
sounds rather like Self, though I've never actually seen any 
Self code.  If a class is basically a collection of respond_to?s 
, then what is the benefit of a class, except as a way of 
knowing which things will be responded to?

Imagine an entity object, perhaps basically a sorted array, that 
can look up a method, and determine who would respond to it.  It 
has basically two functions.  It can register a method, and it 
can invoke a registered method.  So inheritance becomes 
automatically registering the methods of the ancestor.  But then 
the ancestor could be anything that has (determinable) methods. 
  E.g., a singleton object.  With this analysis, it's inviting 
to presume that there might be a way to copy methods between 
entities, though there would need to be some way to ensure that 
all of the needed state variables were also copied.  But in Ruby 
a variable is created whenever one stores something.  Still, it 
might be desireable if it were possible for the necessary 
variables to be initialized.  Modules let one do this by hand, 
but might there be a better way?  I keep thinking of 
chromosomes, but that doesn't really sound right.  Perhaps like 
it's just a method that was "good enough".  Better might be if 
def's had an optional initializing section that was invoked the 
first time the function was called.  And conditional 
initializing statements (don't create this variable if it 
already exists, but if it doesn't, this is the initial value). 
And static variables (which might be thought of as class 
variables with the name prefixed by the name of the def, though 
in implementation their visibility is restricted to within the 
def that they are defined in.  So a def could be a small piece 
of stuff that did things, and could often be copied from 
environment to environment, without too much concern.  Like 
those small rings of DNA that some bacteria share around.

Some of this sounds to me like a description of how Ruby works. 
  Some of it sounds like it might be too expensive to be 
practical.  Some of it sounds like ... well, perhaps like 
something that might be in Ruby 1.8, or 2.0.