For those that don't have HTML capable mail readers...sorry for any
inconvenience.

- Stephen

-----Original Message-----
From: Stephen Pair [mailto:spair at advantive.com]
Sent: Wednesday, January 27, 1999 9:19 PM
To: Squeak
Subject: Reification of object references


A number of messages circulated a while back concerning the reification of
object references and messages.  As time passes, I become more and more
enthused about the possibilities.  It seems to me that aspect oriented
programming would be made trivial with these tools at our disposal.  Has
anyone researched how one might go about reifying object references or
messages?

I've thought a little about how one might reify object references, but I'd
like to hear some other viewpoints on the topic.

The first thing that occurred to me was that there was a great risk of
severely impacting performance (time and space).  To avoid the problem, it
should be implemented in a way that generic references remain direct or
"immediate" references.  Thus, we would need some way of determining whether
a reference was immediate (an implicit instance of the generic object
reference) or indirect through an instance of an ObjectReference.  I believe
that all object references are 32bit aligned, is this true?  If so, then all
object references should be evenly divisible by 4 and the lower 2 bits
should be available for use (correct?).  Since SmallIntegers are denoted by
the least significant bit being set, this leaves the bit in the 2's position
available.

Using a mask of 16r02, the VM would determine whether or not a reference was
immediate or indirect.  In the indirect case, the VM would send a Smalltalk
message to the reference to either get or set the reference.  Methods could
be provided in Object to get and set object references (#referenceAt:,
#referenceAt:put:), which would handle the bit manipulation.  In addition,
methods to reify and un-reify (is there an antonym?) references could be
provided in Object.

A useful hierarchy of object references could then be implemented such as:

ObjectReference
     WeakReference
     TransactionalReference
     etc...

In thinking about this problem, it originally occurred to me that <- ( or
:=) could be treated as though it were a binary message, and in the case of
a reified object reference, would actually be sent to an instance of object
reference...however, it further occurred to me that there is in fact an
inconsistency in the language with regard to <- when viewed as a binary
message.  For example, consider:

     instVar <- 'some string'.
     instVar asUppercase.

....in the first statement, '<-' would be a message sent to the object
reference (when viewing it as a binary selector), however, the second
statement is understood to mean send 'asUppercase' to the target of the
reference...thus, the inconsistency.  Perhaps we should be writing code
like:  " *instVar asUppercase " or " &instVar <- 'some string' "  ( just
kidding :), but the similarity is worth noting ).

It also occurred to me that it might be useful for the ObjectReference to
know what variable in what object is being set (so <- is insufficient for a
setter message).

One other interesting prospect is that reifying object references may be
useful in eliminating many of the common uses for #become:.  For example, in
the case of proxy objects, if an object were able to require an specific
object reference to be used when referring to it, then proxy objects could
have a single associated reference object that all referring objects would
share.  Then, it would be a simple matter of setting this single reference
rather than doing a #become: when the proxy is realized.  This would also
imply that chaining object references be supported.

I have not put any thought into the implications this might have on
collections?  Perhaps someone else has some ideas here?

Regards,
Stephen




Content-Type: application/octet-stream;
	name="Stephen Pair.vcf"
Content-Disposition: attachment;
	filename="Stephen Pair.vcf"

Attachment converted: Anon:Stephen Pair.vcf 2 (????/----) (000065B8)