Re: interned objects

Alessandro Colomba <[email protected]> writes:

>>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

The idea is to intern the *types*, not the instances, though you can, of
course, do that too (see below).

> b) identical deserialized interned objects would become the very same
> object, even after a restart.

Correct.

> 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.

I'd envisage all types to be interned automatically, so you won't have
to specify anything.

> Then, if one also wanted property b) on some objects (e.g. a shopping
> cart), one could take care to intern it.

Yep. That's exactly what would happen.

> c) serialized equal? but distinct interned objects would become the
> same object upon deserialization.
>
> Is this correct?

There is no such thing as a "serialized equal? but distinct interned
object". No two interned objects can be equal? without also being
eq?. When you call (intern <value>) you *get back* an interned
object. So if you have
  (equal? v1 v2) ;=> #t
  (define v1i (intern v1))
  (define v2i (intern v2))
then
  (eq? v1i v2i) ;=> #t
  (equal? v1 v1i) ;=> #t
  (equal? v2 v2i) ;=> #t
That will also be true after deserialisation. Note that *nothing* is
said about the intern status of v1 and v2, and the eq? relationship of
either v1 or v2 to v1i and v2i.

This in fact points out a weakness in the proposal so far: it would
usually be the case that
  (eq? v1i v1) ;=> #t
  (eq? v2i v2) ;=> #f
Hence v1 would be considered interned, but v2 wouldn't. Effectively,
interning is a mutating operation, which it really shouldn't be - it's
meant to be a function producing an interned value. There is an easy
solution to that: make (intern <value>) store & return a shallow copy.


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