interned objects

SISC's serialisation of records is currently broken because the records
implementation identifies record types by their object identity, which
changes on deserialisation.

A similar problem exists with serialisation of objects in SISC's oo
system.

Essentially, the problem boils down to different notions of type
equality. Should types be considered equal when
a) they are the same object (this is the current situation),
b) they have the same name (aka nominal typing)
c) they have the same structure (aka structural typing)
d) they have the same structure and name

For reasons of implementation efficiency, a) is preferable, since it
makes type equality a simple pointer comparison. a) is also the safest,
in the sense that it definitely won't equate types which shouldn't be
considered equal. However, only b)-d) work well with serialisation. Of
these, d) is the safest. It can still break since, for instance, record
types do not record information about their field types, so it is
possible to have two record types with the same name and structure but
different expectations wrt to the contents of the fields. I reckon that
is an acceptable risk though.

The question then becomes of how we can implement d) without sacrificing
the efficiency of a). One way to do this is to ensure that the two
notions of equality coincide. This can be accomplished by "interning"
objects, i.e. maintaining a (weak) set of objects under structural
equality. That's exactly what happens with symbols in Scheme. So we
simply need to generalise the symbol interning scheme to other types of
objects.

Here's a possible solution:

A function
  (intern <value>) -> <value>
that interns any value in a weak set under equal? equality. On
serialisation of any value we check whether it is a member
of the set under *object identity*. If so, we mark the object specially
in the serialised output. On deserialisation, any objects thus marked
will be re-interned.

The advantages of this solution is that it is completely orthogonal, and
relatively easy to implement. The disadvantage is that surprising things
may happen when the intern status of an object changes over
time. Problems will also arise when interned objects are mutated. I
think though that the answer to both of these issues is "just don't do
that" ;)


Comments? Thoughts?


Matthias.



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf