Andreas Raab <andreas.raab at gmx.de> wrote:
> My proposal (unless other really good arguments come up) is the following:
> Make ContextTag fully polymorphic with MethodContext (the only required
> change is add #restartWithNewReceiver: to method context) and then - by
> default - have MethodContext>>contextTag return self instead of an instance
> of ContextTag.
> If I understand the changes correctly, then its only implication is the one
> we're living with today (e.g., being unable to copy call stacks "correctly"
> without additional work).
> Then, provide a package for ContextTag which - if installed - simply changes
> the implementation of MethodContext>>contextTag to return an instance of
> ContextTag (which may or may not be stored in the receiverMap). This would
> allow applications which require cross-process continuations to use this
> particular slot while not assuming that there is a de-facto use for
> receiverMap throughout Squeak.

You and Avi are right.  ContextTag just allows copied call-stacks to work
correctly (I'll make the class comment clearer).  And your also right that
keeping a slot free for Context experimentation is important.  But I would
still like to have working stack copies in conjunction with possible other
experiments like delegation.  What if we used receiverMap to hold a record
containing the ContextTag and other slots as desired for delegation, JIT, etc. 
Then we can have all at once instead of choosing.  The record would only be
created on demand (contextTags are only needed for signal contexts and block
closure homes).  And the extra indirection is still pretty cheap.  What do you
think?

Cheers,
Anthony


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com