[elephant-devel] Transient slots in non-persistent objects

[Ben]

>  Why do you need to subclass it?  Can't you just define an :around
> method for standard-slot (or whatever it's called)?  Then defclass
> wouldn't need to do anything special.  I haven't thought this through,
> it's just an idea.

an around method specializing on the standard slot-definition would
affect all slots in all classes, unless there's something clever i'm
not seeing.

>  Hi, by the way!  I decided a couple days ago to give Elephant a try.
> It was slightly annoying to install the prerequisites (I wish asdf-install
> were integrated with fink), but I got everything working.  It's a lot
> more impressive than I thought it would be.

hello!  yes, i wish there was a way for a quicker install.  but
there's a lot of C code.....

>  While I'm writing, might as well ask my question.  It's not clear
> from the manual:  Is there any way, kludgey or otherwise, to
> redefine a persistent class and have all instances of it be updated?

it depends on what you want.  things that should "just work": adding
slots without new default / computed values; removing slots (though
this may leave some garbage in the DB.)

basically, as explained in the tutorial, there is no "table layout"
for persistent objects, so there's usually no need for things like
"schema update."  objects are put into the database, one row per slot,
keyed by OID and slot-name.  unbound slots are "empty rows."
therefore if you add a slot to a class, every instance will get that
slot, it will just be unbound.  if you remove a slot, there will be a
bunch of garbage rows in the DB (and hope you don't add that slot back
or else you might get confused!)  eventually when a garbage collector
is written, those rows will be collected.

if you want to do something fancy with default values /
reinitialize-instance, you may need some finesse.  if you know where
all instances of the affected class are, you can of course manually
load them and do whatever you want to them.  the problem with the
CLOS-standard change-class / redefinition machinery is that they
assume all instances of the object are "in memory", which of course is
false for any persistence mechanism.  i'm thinking that i might want
to add a bit to the MOP in that we might need a protocol which
distinguishes between creating a new instance and creating an instance
which is already in the database.  on the TODO list.

thanks for the interest, B