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

[Leslie P. Polzer]

Hi Ian,

thanks for making it clear. Of course, I guessed this and the Elephant code
I looked at didn't say otherwise, but you're knowledge is obviously greater.

> The right user approach is to provide a function to walk over
> instances and update their representation or zero them out.  Other
> than an assertion on deserialization or a general warning on type
> change, I can't think of a really useful default policy.

I can, sort of: Elephant should offer an easily usable facility
to specify what should happen when the types don't match, something like

(defmethod elephant:convert-slot ((from pic) (to string)))

which is pretty much exactly what convert-class is for, so we might just use this.
Wouldn't it suffice to just do

START) type changed? [this decision should be based on the :type slot-initarg]
   Yes: call convert-class
    No: simple assignment


> Have you tried this and seen what happens?

Neither warning nor error, just assignment of the old data.


> What Lisp are you using?

I'm using SBCL/Linux/x86.

This functionality is important IMHO; without it, sensible Lisp-style Rapid Prototyping
is hardly possible when one needs to call map-root everytime something changes.

  Leslie

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