For those that don't have HTML capable mail readers...sorry for any inconvenience.
- Stephen
-----Original Message----- From: Stephen Pair [mailto:spair@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)
squeak-dev@lists.squeakfoundation.org