becomeForward: problem revisited

Chris Muller afunkyobject at yahoo.com
Wed Mar 26 03:31:10 UTC 2003


Last year, we had a discussion on the list about becomeForward:, where:

  String new becomeForward: #MyClassName

copies the hash-bits of myObject over the hash-bits of #MyClassName, causing it
to get "lost" in the various hashed collections, such as Smalltalk.

Bob Arning had made a.. pretty good argument that copying the hash-bits was
"correct" because you would want any proxies in hashed collections to not get
lost.  Here is that message for a refresher:

  http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-May/039766.html

However, now, with more experience with Magma, I don't feel it is a valid
argument afterall.  That's because copying the hash bits is problematic for the
following scenarios:

  - objects already present in the image, such as Symbols
  - objects that override hash and =.  When the proxies to these kinds of
objects are materialized, their calculated hash will still change and cause the
same problem.

One of Magma's best requirements is that it provides transparent access to all
standard kinds of Smalltalk objects, including Symbols.  Symbols are a part of
many domain models, sometimes as method selectors.  In that case, I have
discovered that a becomeForward: to a method selector Symbol causes it to not
be able to be found in its methodDictionary, resulting in a doesNotUnderstand
when I try to perform it.

I could use a ReadStrategy to force Magma to always read referenced Symbols and
thus avoid the proxys for them.  But this requires me to specify them by class
and variable name, which is cumbersome and reduces transparency. 
ReadStrategies were intended to be 100% optional as a PERFORMANCE tool only. 
Additionally, tracking down bugs caused by changing identity hash due to a
proxy materialization is.. not trivial, to say the least.

My hack-solution last year was to rehash the Smalltalk global and the Symbol
table whenever I becomeForwarded to a Symbol.  While only somewhat of a
performance issue, this solution is now actually unworkable for the method
selector Symbols since I won't know which methodDictionaries to rehash.

Avi had suggested a bit flag in the stored object-buffers to indicate
referenced Symbols.  Since I would have to know this on the "referencer" side
(instead of the referencee side), it'd have to be a bit in every single object
oid that the server would have to check this, multiple times, for every single
buffer read.

To me, the best solution is to simply have a becomeForward that doesn't change
the identity of the target.  It really should be completely non-mutative to the
target object.  I realize that the decision to copy the hash-bits was made with
good intentions, but if it was for preserving identity of proxies materialized
to real objects, it is inherently flawed.

Whether we can agree that copying the hash bits is "correct" or "incorrect", is
there any chance of at least factoring out that behavior in a future version of
Squeak, so that I can do a becomeForward without the hash-bits copy?

In the meantime, unfortunately, unless I can think of another solution, I'll
have to add, "Don't use Symbols in your persistent model" to the Magma Best
Practices page.

Comments?


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com



More information about the Squeak-dev mailing list