How to create a self-desribing BlockContext?

shaping at bigfoot.com shaping at bigfoot.com
Thu Sep 9 19:41:55 UTC 1999


----- Original Message -----
From: Dan Ingalls <Dan.Ingalls at disney.com>
To: <shaping at bigfoot.com>
Cc: <squeak at cs.uiuc.edu>
Sent: Thursday, September 09, 1999 10:50 AM
Subject: Re: How to create a self-desribing BlockContext?


>I need a new BlockContext that describes the send it contains, in terms of
>receiver, selector, and arguments.  I need these as instance variables, so
>that I can compute a hash to determine the block's uniqueness.  Current
>BlockContexts seem to be instantiated as modified clones of an blank block
>in the "special objects" array.  I don't see immediately how to work with
>this situation.  My first thought is to create another special object and
>modify the block syntax slightly and the parser accordingly, to accommodate
>the new blocks without messing up the old ones.  Any suggestions on how to
>created the new BlockContext class would be appreciated.

BlockContexts are treated specialy by the VM so it is unlikely that you can
get things to work with your own implementation, except as a simulation.
It's hard to make suggestions, since you haven't said what you really want
to do.  The text of your message seems to imply that your blocks are very
simple, as

[rcvr selector: arg].

Right:  a single send of any complexity.  No block arguments.  Block must be
a able to respond to value protocol and return the result of its contained
send, as usual.  Home context is not required.



If this is the case, then you could just as easily use an instance of
Message (or a subclass which you could eeasily write that included the
receiver) instead of a block.

This is what I'm trying to avoid, in the interests of brevity and clarity.
It's my last resort.

  It would be easy to hash and compare these, and it would be easy to get
the equivalent of the #value method by using the existing #sentTo: method.

PS  Of course it is easy to determine a block's uniqueness

By "uniqueness", I mean pragmatic, behavioral uniqueness, not
implementation-level uniqueness as indicated by pc, stackp, sender, etc.
Essentially, it needs to work like a block and describe itself like a
Message.  Presently, I can create from one block declaration two instances
whose pc and startpc differ.  This makes their hash values different,
allowing unwanted multiple inclusions in sets.

using ==, and its response to identityHash should also work fine for you.
There are more things that blocks can easily tell you, such as what method
they are from, in what class, and so on.  If you must use blocks, I can even
show you how to make it look like rcvr, selector and arg are instance
variables in a simple case like that above, but it won't be quite so simple.

Please do.  One condition though:  the solution has to be fast; there can't
be a lot of indirect access to the receiver/selector/argument features of
the block.   I don't mind working out a complete solution to this problem,
in any event.



Shaping





More information about the Squeak-dev mailing list