Re: interned objects

Thank you Matthias. Before It wasn't clear to me when you were
referring to interning types vs. interning instances.

So to recap:

a) Types would always be interned based on their name and structure.
b) Instances could be interned by the user at will.

The last (I think) question is then, what happens if one:

1. interns an object v,
2. serializes it to file x,
3. mutates it,
4. serializes it again to file y
5. deserializes x and y into v1 and v1.

Would v1 and v2 still be eq?, i.e. would one state of object v
override the other?
___
Alessandro




On 8/13/05, Matthias Radestock <matthias@xxxxxxxxxx> wrote:
> Alessandro Colomba <acolomba@xxxxxxxxx> 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