partial construction and deconstruction

[Mark S. Miller <vlad!mark>]

Date: Tue, 21 Aug 90 01:32:44 PDT
   From: xanadu!tribble (Eric Dean Tribble)

   ... I strikes me that when becoming between related objects
   (the only become really allowed), it might make sense to destruct to
   the lowest shared superclass, then construct from there.  ...

   Is this possible?  What do you think?

It does make sense.  Unfortunately, it doesn't strike me as possible.
It is possible to partially destruct by BLASTing out of the
appropriate superclass contructor, with the BLAST being caught by a
SHIELD in the "become" code.  Since destructors cannot be directly
parameterized, it'll involve some ugliness to get the destructor to
BLAST appropriately for this case.  However, I see no easy or portable
way start a construction process in the middle.

Well, now that you mention it, I do see a sneaky way of doing it.  But
it would seem to introduce a client-level complexity which may be
worse than the pain you're currently going through.  I don't recommend
persuing this, but I'll describe it anyway.

If class A mayBecome class B, and their common superclass is class C
(which may be arbirarily far up the superclass chain from either),
then B would have a constructor for becoming given that it was
starting from an A, and so would B's superclass on up to the ancestor
of B which is an immediate subclass of C.  This ancestor's
becomming-from-A constructor would in turn invoke C's change-class
constructor, which would just do change-class-constructors on up with
no effect.  Only when C's change-class constructor returned would the
real construction work begin.

Where this gets really ugly is: Let's say that D may also become B,
but D's common ancestor with B is E.  Then B would also need a
becomming-from-D constructor which did real construction up to E and
change-class construction from there on up.  You could simplify this
by saying that everything which may become a B has to accept the same
superclass of B as the rendezvous point, which may even be specified
as the first ancestor of B which doesn't have a NOT_TYPE annotation.
Then, at least, you wouldn't need a combinatorial number of
become-constructors.

Notice that you cannot parameterize B's constructor as to where the
join is by using data (which you can do on the destruction side),
because it is a static property of a constructor which superclass
constructor it invokes.  This invocation cannot be put inside an "if".

Semantically it makes sense to do what you described, but it would be
a sufficient implementation nightmare that you should go ahead and
pass an ungodly number of arguments.  Let's keep the idea around for
future language designs though.

Btw, what about Smalltalk?  Even if we did solve this in C++, how
would you write the Smalltalk side of this?  It would seem that most
of the same problems show up there, and because the become-target is
actually a different storage-object, it would be even harder to solve.
Whereas the pass-ungodly-number-of-arguments trick simply works the
same way in both languages.