<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Reification of object
references</title></head><body>
<div><font face="Arial" color="#000000">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?</font></div>
<div> </div>
<div><font face="Arial" color="#000000">I've thought a little about
how one might reify object references, but I'd like to hear some other
viewpoints on the topic.</font></div>
<div> </div>
<div><font face="Arial" color="#000000">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.</font></div>
<div> </div>
<div><font face="Arial" color="#000000">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.</font></div>
<div> </div>
<div><font face="Arial" color="#000000">A useful hierarchy of object
references could then be implemented such as:</font></div>
<div> </div>
<div><font face="Arial" color="#000000">ObjectReference</font></div>
<div><font face="Arial" color="#000000">
WeakReference</font></div>
<div><font face="Arial" color="#000000">
TransactionalReference</font></div>
<div><font face="Arial" color="#000000">
etc...</font></div>
<div> </div>
<div><font face="Arial" color="#000000">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:</font></div>
<div> </div>
<div><font face="Arial" color="#000000"> instVar
<- 'some string'.</font></div>
<div><font face="Arial" color="#000000"> instVar
asUppercase.</font></div>
<div> </div>
<div><font face="Arial" color="#000000">...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
).</font></div>
<div> </div>
<div><font face="Arial" color="#000000">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).</font></div>
<div> </div>
<div><font face="Arial" color="#000000">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.</font></div>
<div> </div>
<div><font face="Arial" color="#000000">I have not put any thought
into the implications this might have on collections? Perhaps
someone else has some ideas here?</font></div>
<div> </div>
<div><font face="Arial" color="#000000">Regards,</font></div>
<div><font face="Arial" color="#000000">Stephen</font></div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div><br>
Content-Type: application/octet-stream;<br>
<x-tab> </x-tab>name="Stephen Pair.vcf"<br>
Content-Disposition: attachment;<br>
<x-tab> </x-tab>filename="Stephen Pair.vcf"<br>
<br>
Attachment converted: Anon:Stephen Pair.vcf 1 (????/----)
(0000656E)</div>
</body>
</html>