[elephant-devel] recreate-instance-using-class
Alex Mizrahi
killerstorm at newmail.ru
Tue Jan 8 12:10:17 UTC 2008
helo
there was a patch that alters the way how objects that are deserialized are
created: it uses allocate-instance and bypasses normal initialization
sequence of make-instance.
however, there was no documentation given how this is supposed to work, so i
thought this shouldn't affect applications.
but we've found that sometimes it has disastrous effects in some cases.
for example, we've found that "strange bug" Robert saw in postmodern backend
happens because initialize-instance of pm-btree is not called.
it seems now we should use recreate-instance instead of initialize-instance,
because descendants of "persistent", like btrees and other internal classes,
are completely deprived from normal Common Lisp initialization functions. if
this is intentional, probably it's worth documenting this, because finding
such stuff from weird bugs isn't very pleasant.
also, it seems initargs/initforms won't be initialized on recreated
instances of persistent, at least i don't see any way how they could be
initialized. we should forget about this functionality for internal
elephant's persistent classes?
or this damage was not intentional? as i understand, elephant users are
supposed to work with persistent-object, but not persistent class, so maybe
this patch should only affect persistent-object?
it's also quite strange that recreate-instance for persistent-object calls
shared-initialize, but for persistent it doesn't. looks like intentional
sabotage! :)
but it's not clear how this stuff should affect descendants of
persistent-object. if people used initialize-instance :after to intialize
transient slots, how are they supposed to intialize them now?
shared-initialize :after? or they should use ele::recreate-instance?
with best regards, Alex 'killer_storm' Mizrahi.
More information about the elephant-devel
mailing list