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/
_______________________________________________
elephant-devel site list
[email protected]
http://common-lisp.net/mailman/listinfo/elephant-devel
