On Jan 8, 2008 3:31 PM, Ian Eslick <[EMAIL PROTECTED]> wrote:
> Actually I think we definitely need to fix this. Quite a few people
> have run into the problem that we're violating the CLOS contract on
> make-instance and that we should not use the same CLOS calling path
> for re-initialization that we use for initial creation. I think we
> should require new contracts rather than messing with familiar ones.
>
> One proposal was to create a placeholder class and then call change-
> class on it, but that still evokes the initargs for new slots and
> creates problems of its own. Another one is to make a cheap
> placeholder that is only initialized when touched, which I like but
> can't think of how to implement.
>
> As the next step, I think we probably want to figure out, for
> deserialized instances, how to create a minimal instance, initializing
> transient slots only, handle any schema evolution we choose to
> implement and then call a generic function (reconstitute-instance)
> that users can define methods on to do any deserialization time
> specialization. This way the users can do the usual 'on creation'
> specialization on initialize-instance without having it called
> multiple times in unexpected ways.
Hi all,
I've been giving this some thought and without investigating how much
work this would take
I see the loading of persistent instances working something like this.
We (actually in this case i only speak for myself) want something which,
a) Allow customization of both instance creation and instance deserialization.
b) fits in well with the current initialization & reinitialization protocols.
c) Is relatively (for some value of relatively) non obtrusive.
With that in mind I would propose something like the following.
Deserializing instances is done using recreate-instance. This method
allocates a new instance of the class using allocate-instance and
passes this to reconstitute-instance which falls through to
shared-initialize which does all the dirty work.
(recreate-instance (persistent-metaclass))
-> (allocate-instance (standard-class) &rest &key)
-> (reconstitute-instance (persistent-object) &rest &key)
-> (shared-initialize (persistent-object) t &rest &key)
This should satisfy everyones requirements, allowing specialization of
methods for instance deserilazation, instance creation or both using
initialize-instance, reconstitute-instance and shared-initialize
respectively.
This would also make it relatively easy to add in schema evolution by
adding a :before method on
reconstitute instance.
The only drawback that is immediately apparent to me is that this can
break backwards compatibility since there may be specialized methods
on initialize-instance that will no longer be called, although this
can be easily worked around by specializing on shared-initialize or
altering reconstitute-instance to call initialize-instance.
comments?
cheers,
sean.
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
