On Mon, Jan 12, 2009 at 04:38:07PM -0800, Jon Lang wrote:
: No, you don't understand me. The Foo/Bar example I was giving was
: independent of your example. Rephrasing in your terms, consider the
: possibility of a class that's derived from Array, for whatever reason;
: call it "Ring". Now you decide that you want to redefine Array to
: include a shuffle method, and so you implement an "Array version 2.0".
: Would you be given a "Ring version 2.0" that derives from Array
: version 2.0, or would you have to explicitly ask for it?
When a Ring object refers to Array that reference is supposed to be
virtual, so at least going that direction, the Ring object will be
implemented in terms of Array 2.0, if that is the meaning of Array to
the current object. Extending that back into BUILD time, this implies
that in "class Ring is Array", the new Ring object needs to know how
to make Array virtual even though the object isn't constructed yet.
Neat trick, if we can pull it off...
Possibly when we compile the Ring protoobject in a lexical scope
with Array ::= Array:ver<2.0>, at that point we can record with the
new Ring alias that any new Ring object made with that protoobject
must use Array:ver<2.0>. Or something like that. For the situation
to arise, the lexical scope must know about Ring objects somehow.
This would handle the explicit
use Ring;
case, but I'm not so sure about indirect Ring objects that come
in from elsewhere. They might have already been constructed with
Array:ver<1.0>. Not sure what we can do about that. It doesn't seem
like the kind of info you want to carry around with every object,
so you end up attaching it to the type. If you get an object of two
different versions, at some point you end up re-inventing version
control merges for object attributes, and then you're probably
just hosed.
Or you just call it a "sync" and pretend it's no problem. :)
Larry
