On 8/12/05, Matthias Radestock <matthias@xxxxxxxxxx> wrote:
[...]
> The interning will be done automatically by the deserialisation. When
> you serialise an interned object and then deserialise it you will get
> exactly the same object back. If you serialise the same interned object
> several times, then deserialise them all after a restart, you will end
> up with exactly one object.
I am not sure I properly carried my point across, so allow me to
rephrase in light of your explanation.
>From what I understand, you are saying that the intern function would
afford two properties:
a) deserialized interned objects would belong to the same type even
after a restart, and
b) identical deserialized interned objects would become the very same
object, even after a restart.
I can imagine scenarios in which I would happily give up b) in
exchange for not having to intern objects explicitly, as long as a)
were transparently available.
It seems to me that one way to obtain a) would be to essentially use
nominal typing, with the twist of objects types being identified by
the user-given type name and the slot names (all encoded in a symbol.)
Then, if one also wanted property b) on some objects (e.g. a shopping
cart), one could take care to intern it.
Also, I have a question. From your description of the implementation
of intern, it would seem to me that another property would be
introduced:
c) serialized equal? but distinct interned objects would become the
same object upon deserialization.
Is this correct?
___
Alessandro
-------------------------------------------------------
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
|
