On Apr 27, 2007, at 6:36 PM, Pierre THIERRY wrote:
Scribit Ian Eslick dies 27/04/2007 hora 15:37:The persistent slots of that class have the allocation parameter :database instead of :instance to capture these semantics.Should'nt that be orthogonal? Currently, that means persistent classallocated slots are not supported. I never had to use them, though, so Ididn't think much about their usefulness...
That is correct, we don't store class objects of any kind at this point either.
You might read metaclasses.lisp and classes.lisp if you want a deeper understanding of how this works.Yes, I only gave them a superficial look before, only to add some locks around slot access (which was surprisingly easy, and though it might nothave been very clean, it was working for me...).
Actually at this point you shouldn't need to put locks around slot access. All slot operations are transactional at the data store level even when they're not in a formal transaction so thread safety should come for free. (Unless you've caught some shared access in the slot protocol that I've missed).
You can't call reinitialize instance unless you have an instance to reinitialize. When you are deserializing a persistent object reference and the object isn't in memory, you need to create storage for at least the oid and store-controller reference.That's making a placeholder instance, not making a persistent class instance, semantically.
That would explain some of the confusion! The placeholder instance (according to your definition) in Elephant is an instance of persistent-metaclass and inherits from persistent-object, so it is a persistent-metaclass instance, strictly speaking.
I'd be curious what a persistent class instance would look like by your semantic definition. Do you mean an object that has its slot values in memory rather than in the database? (like prevalence objects?)
If you are creating an object, why not create one using the class of the one you are going to use rather than invoking more generic function overhead to copy values around?Because you're not creating an instance of it, you're creating storage to hold an already created instance of it.
Or perhaps it's the awkward semantic use of the MOP API you are bothered by, not the low-level dynamics of storage management that it executes?
I'm open to a better solution to handling slot initialization in the fresh vs. reconstituted cases.I'll think on it. It's very pleasant to know a proposal will be welcome.
Of course I can't guarantee to make the change in any particular timeframe. If you really want to clean this up the best way is to go in and do it yourself!
I've cleaned up quite a bit of the internal design and API since I started working on Elephant because it impinged on what I wanted to do in my own projects, the initialization isn't something I'm terribly concerned about as it hasn't bothered me much. I have a mile long list of issues like this I've discovered while updating all the code Robert and I inherited. (I think I just logged Trac ticket #50 today).
Speaking of Trac, this would be a great issue to document in a Trac ticket or on the wiki, you should be able to submit them as an anonymous user now. If you have a common-lisp.net account you should have a Trac password and can login and edit the wiki or submit Trac tickets under your own common-lisp.net uid.
Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
