[or perhaps tidier, "self.class.new"]
will result in this behavior
sub = SubClass.new
sub.method.type >> SubClass
A recent example of why this might be a good design pattern is that
subclasses of Array must re-write all the 'usefull' methods like select, etc.
to return the SubClass'd type since these methods return an Array.
This was actually discussed about a week ago, specifically taking the
example of class 'S' derived from 'String', where the inherited '+' method
in S returns a String not an S.
I can hear the arguments against :
"what if the subclassed methods do something perverse with the methods"
"what if the subclassed methods simply will not work if that is done"
I would say
Sub-classing should always be reserved to _extend_ objects, old behavior
should always remain - but may be added to.
Another objection centres around the arity and semantics of constructors.
Your code above assumes that all derived classes will have a constructor
which allows zero arguments. But this may not be true.
For a start, there are objects for which zero arguments are not meaningful:
ArgumentError: wrong # of argument
from (irb):1:in `initialize'
from (irb):1:in `new'
That's not really a problem because in that case your code would say
self.type.send :new (arg)
However, say that a base class has a constructor which accepts 1 argument.
It does not necessarily follow that all derived classes will have a
constructor which accepts 1 argument: a derived class may well have other
instance variables which need initialising, and it may only make sense to
have a constructor which takes (say) 2 arguments.
In that case, self.type.send :new (arg)
will fail, even though it is fine in the base class.
You could _require_ that all derived classes implement a constructor with
the same arity as their parent class even if it would not normally make
sense to have one, perhaps taking defaults of 'nil' for the extra arguments
it needs. In that case it would be a kind of type coercion operator: "give
me an object of type SubClass, even though the parameters I am going to give
you are only sufficient to create an object of BaseClass".
You can't just create an instance of the base class using the base class's
constructor and just 'flip' the type to be SubClass; that would leave the
subclass's extra instance variables uninitialised, potentially giving you an
invalid object instance.
Oh, and remember that inheritance can have multiple levels. So given
Sub1 < Base new(arg1,arg2)
Sub2 < Sub1 new(arg1,arg2,arg3)
then Sub2 would have to implement constructors of all three variants, just
so that it could use inherited methods from Base and Sub1 which construct
new objects of type "self.class"
This is all pretty nasty, because you can't write a working implementation
of Sub2 without knowing about all the different ancestor classes.
It would get even nastier if the subclass constructor has the same arity but
different semantics (e.g. Base.new takes a string but Subclass.new takes a
Regexp; or Subclass.new takes a string but does something different with it)
So, perhaps it would be cleaner to explicitly create an object of the base
class and then ask the subclass to "convert" it, which might involve filling
in its extra instance values with appropriate values or defaults.
# instead of self.class.new call:
Base.create_from_Base is a virtual method, to be overridden in subclasses.
Effectively you have a new type of constructor: "construct given an instance
of a parent class", rather than "construct given some parameters".
You need a mechanism to perform the chaining required with multiple levels
of inheritance: for example, if 'a' is an object of class Sub2, then calling
'a.method' will call Sub2.create_from_Base, but this in turn needs to call
Sub1.create_from_Base followed by Sub2.create_from_Sub1.
I guess this could be done, by walking self.class.superclass up towards
Object. Sounds like quite a lot of scaffolding to run every time you create
an object instance though.
On Sat, Nov 09, 2002 at 12:52:24AM +0900, ahoward wrote: