Re: shower strikes again (whap!)

[Michael McClary <michael>]

> a couple problems with this:
> 
> 1) stubs don't have identity.  Several stubs might virtually point to
> the same object.  I can imagine making them canonical, but it could be
> expensive:  I expect at least 3 times as many stubs as shepherds.

Wait a second.  That's not true, at least for the version I'm doing.

Why should there be multiple stubs in-ram for the same out-of-ram
object?  All the pointers which caused the stubs to exist came into
existence by pointing to the same object.  The creation of the stub
is mediated by the ViewHandler/Snarf(Un)Packer, which knows where all
the already-in-ram stubs and disk-wise shepherds are, and can as easily
hand back a pointer to one that exists as cause creation of a new one.

> 2)I don't think objects can be changed in place in a portable fashion.
> MarkM?  Hill?

If objects can't be changed, then changing a stub into a transparent
forwarder of the appropriate subclass doesn't work either.  We could
work around that by insisting that no subclass of a shepherd represented
by a concrete stub can implement a new message, but that's dirty.

On the other hand, we can do it in Smalltalk, we can do it in cfront 2.0
(unless I've missed something major), it's only used by the backend,
(in the platform-dependent bottom layer - notice that we're already
doing this separately for smalltalk and X++), and I thought we had decided
to punt backend portability beyond cfront 2.0 until after first release.

If, later, we must port the backend to a platform where we can't convert
objects in-place, the changes should be confined to this low-level lump
and its stubble script.  The bulk of the backend code ignores this man
behind the curtain.

> We should definitely keep this in mind though.  It does simplify some
> things.  It might actually be easier than forwarding messages if
> objects can be recreated in place.

Sure is easier for >me<.  B-)

> Your assumptions were correct,
> all shepherds are small (4 pointers max?), and even the things that
> mutate stay within a pointer of their original size.

Great!  Are there any things that mutate while being pointed at by half
the world?  (Changing the annotation on the inter-snarf pointers that
point at them could require pulling in lots of snarfs, which would be bad.
On the other hand, I suspect we don't now have any ent-objects that change
type in-place, or we wouldn't be having this conversation, right?  B-) )

> On the question of object mutation, here we're talking about changing
> an object to another implementation of the same compile-time type.
> This is completely transparent to the rest of the program.  If we can
> do it, I think it is a clean functionality to support.

Check.  And since it's the same thing as changing the stub into a forwarder,
it's no more work.  (Less, since we don't have to write stubble scripts
to generate forwarders.)

	michael