The new Constructor Bomb stuff

[Mark S. Miller <vlad!mark>]

Abstract: In moving from "saveThis" to constructor bombs, some
additions were made to X++-in-C++, and some changes were made to the
translator.  The result in Smalltalk is (unfortunately) not strictly
upwards compatible.  The client interface in each language is
described, as well as how to cope with compatibility.  The following
only applies to Heapers.

*NOTE*:  The following does *not* correspond exactly to what I gave to
Mr. Hill, but is a variation on it which I just realized is what I
need to support "become" as well.  None of this is in Alpha-7, but
it's all coming real soon now.

In X++-in-C++, the old way of invoking a constructor, "new Foo (....)"
is no longer garbage collector safe.  It was never actually safe (as
Mr.  Hill found out and explained in a previous message), but is now
so unsafe that it should only be used under exceptional circumstances
(and probably not before we have XLint able to check for "SAFE"ty, as
per previous mail message).  Instead, we have the following macros to
be used instead:

{
    ...;
    CONSTRUCT(b,Foo,(....));
    ...;
}

should be thought of as:

{
    ...;
    b = new Foo (....);
    ...;
}

except of course that the first form is both garbage collector safe,
and will properly destruct the object if any BLASTs escape the
construction process.  Note that "CONSTRUCT" should be thought of as
corresponding to an assignment *statement*, not an expression.  In
fact it cannot be used in an expression.  Similarly,

{
    ...;
    RETURN_CONSTRUCT(Foo,(....));
}

should be thought of as:

{
    ...;
    return new Foo (....);
}

with the same caveats.  (If you're interested in what it currently
expands to, read the macro definitions in tofux.hxx)


In Smalltalk, two changes were made to the translator.  Recognizing
that invoking various different overloadings of new is quite a useful
trick, we extended the translator so that we can write code which
translates to such an overloading.  Importantly, the code which
translates to an invocation of a new overloading can also mean the
"same" thing in Smalltalk.

In Smalltalk, when we write:

	... (Foo new: 5) create: 7 ....

it now translates to:

	... new (5) Foo (7, tcsj) ...;

Notice that the meaning of the two is quite analogous: The new part
allocates storage for a new uninitialized Foo, with the "5"
parameterizing the allocation.  The instance-create/constructor part
initializes the already allocated object storage so that it can now be
said to be occupied by the object.  Please note that saying 'new'
explicitly in Smalltalk should be done in exactly those extraordinary
circumstances in which one would now say 'new' in C++.  This is a
purely upwards compatible change, as till now it was a translator
error to say 'new' in Smalltalk.


The other change allows our current way of writing constructor
invocations in Smalltalk to usually continue to translate to working
C++ code.  When you write in Smalltalk:

	b _ Foo create: 7.

it translates to:

	CONSTRUCT(b,Foo,(7,tcsj));

Similarly, when you write:

	^Foo create: 7.

it translates to:

	RETURN_CONSTRUCT(Foo,(7,tcsj));

We refer to Smalltalk expressions in which a 'create' message is sent
to a class as a 'default construction expression'.  Whereas before
such an expression was allowed to appear anywhere in an enclosing
expression, now it can only appear as the rvalue in an assignment
statement or a return statement.  Any other use will generate a
translate-time warning and will probably generate a compile-time
error.  This is the infamous non-upwards compatability.  However, most
of the previously 'legal' uses which are no longer allowed were
actually not garbage collector safe.


Finally, the translator treats the 'vector' case, and the var-type
case seperately, but I'll let Dean describe these.


P.S. To probably be considered obsolete (but not immediately
retired?):

	DESIGN_CONSTRUCTOR_BOMB
	PLANT_CONSTRUCTOR_BOMB
	PLANT_CONSTRUCTOR_BOMB_NORMAL_NEW ????
	NEW