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