John Hylands wrote:

> An alternate strategy would be to
> continue to use just the proxy but to add an instance variable to the
> proxy which would be nil when the real object was not materialized and
> would point to the real object when it was materialized.=20

This works, but it is better to have another instance variable as well --=
 a
boolean to indicate whether or not the reference is instantiated. If the
proxy ends up referencing nil (which is a perfectly valid thing to
reference), it will always look like it is not instantiated if you use =
nil
to signify that...

====================

Actually, since nil would almost certainly have a special-oid value in most any
ODBMS implementation, you can KNOW if you have a nil, that is what it
referenced.  No need for an extra boolean field to tell you.

When an object is rendered from the database, each other object it references
is usually represented by an integer oid of some kind.  Each oid value, one for
each instance variable, are converted to one of three things:  1) one of the
special-oid-value objects (nil, true, false, etc), 2) another object that is
already known in the local image, or 3) a proxy if it is not in the local
image.

So, if you have a nil, you know its a nil.  If you have a proxy, you can be
certain it is not a proxy to nil..

In the case of Magma, only mutating proxies are used anyway, not forwarding
proxies.  This maximizes the transparency of the database.  Maybe not from a
messaging perspective, but definitely in terms of the Squeak programming
environment.  Forwarding proxies will be revealed in inspectors, for example. 
They increase your object count and, in practice, I think they would eventually
become visible to the logic program.  doesNotUnderstand: has a bit of a cost as
well, albeit so does become:, but become: happens a max of one time..

Regards,
  Chris

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com