[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
shower strikes again (whap!)
- To: <michael>
- Subject: shower strikes again (whap!)
- From: Eric Dean Tribble <tribble>
- Date: Fri, 1 Jun 90 11:38:33 PDT
- Cc: <xtech>
- In-reply-to: <Michael>,31 PDT <9005311002.AA16986@xanadu>
Wait a second. That's not true, at least for the version I'm doing.
I think this decision is in the SnarfPacker. How does the stuff you
are working on touch this? (Stub generation scripts?)
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.
Yes the SnarfPacker handles it and could keep track of these objects,
but then it has to keep track of approximately 4 times as many
objects. Therefore I've been assuming that stubs are extremely
lightweight and don't get indexed in the SnarfPacker.
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.
I think part of the ent requires a subclass with more messages. I'd
rather not recode it :-)
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-) )
MY TERMINAL'S WEDGED. PLEASE IGNORE THE UPPERCASE.
THE ANNOTATIONS MUST BE ONLY COMPILE-TIME TYPE INFORMATION, AND THAT
CAN'T CHANGE, SO WE SHOULDN'T HAVE TO CHANGE ANNOTATIONS ANYWHERE.