[elephant-devel] Status of Leslie's question and Sean's patch?

[Leslie P. Polzer]

> Please correct me if I'm wrong, but isn't this exactly what Lisp
> does?  If you assign the wrong type to a slot under SBCL, it doesn't
> complain so in this sense Elephant behaves in the same way as Lisp
> does with in-memory objects.  At some point it is our responsibility
> not to shoot ourselves in the foot!

Sure, but I'm not talking about preventing that automatically, but about
giving the programmer an opportunity to do agile development by
specifying what should be done when data types have changed.

I'm so after this not only because it'd be very useful for me, but because
this is exactly the way the rest of Lisp and esp. CLOS/MOP works:
if “do what I mean” won't work, give the programmer an opportunity
to clarify.


> I would like to improve the default behavior and error
> handling of these cases, but the interaction between MOP functions
> such as update-instance-for-redefined-class method and persistent
> instances is pretty complicated.  For example, if you don't map all
> instances of an object after class redefinition, then some objects are
> in-line with an old schema, and some with the new.  That's not a
> problem if the update method is called on class initialization, but
> there is no guarantee from lisp that this will happen because you
> could exit and restart before you've loaded every instance.

Not really a problem. I haven't looked at how the MOP plays into
this, but the following will work:

1) slot of type A
2) slot of type B; data store partly updated
3) slot of type C

as long as *both* the transitions A->C and B->C are defined.
Of course, this way one has to provide a quadratic number of transitions,
but: first, we assume a schema doesn't change *that* often that this
becomes a problem; and if it does, the programmer could still employ
map-root at some point to update them all to the latest schema.
Second, we could at some point in the future provide a protocol
that lets us record schema changes so we can do just A->B->C
whereby a linear number of transitions is achieved.


> Lazy redefinition can't be guaranteed to be consistent.

With the above and the assumption that the programmer doesn't shoot
herself in the foot, it can be guaranteed (correct me if I'm wrong).


> I'm very open to suggestions (although I'm unlikely to implement this
> feature anytime soon).  There has been alot of discussion around this
> area (see Pierre and I discussing class deserialization and
> initialization, part of which should be solved by Sean's patch) that
> the initialization and reinitialization on deserialization protocol
> should probably be rethought.

I will take a look at Sean's patch and the discussions you mentioned,
and try to hack up some more if I see the need for it.

  Thanks,

    Leslie

-- 
My personal blog: http://blog.viridian-project.de/