[elephant-devel] Re: fix of ele-postmodern to work withrecreate-instance-using-class

[Alex Mizrahi]

 IE> I don't have a strong opinion about how this should be fixed, but
 IE> let's make sure we aren't hacking up the initialization to fix a
 IE> fundamental problem with the use of the class hierarchy.  It might
 IE> make more sense if we make indexed-btrees not inherit from persistent
 IE> objects...but that would mean special functionality is needed from
 IE> every data store to maintain persistent properties and values attached
 IE> to persistent-collection objects...

as for me current class hierarchy looks just fine. separation on low-level 
`persistent' and higl-level `persistent-object' seems to be reasonable: this 
adds some flexibility and allows us to implement stuff in unified way.

probably it's possible to make some other "better hierarchy", but i don't 
think that will actually make something actually better, because for now 
internal stuff we have works fine, and end-user are supposed to interfact 
only with `persistent-object', as i understand, so they won't notice 
internal changes anyway.

 IE> If the distinction isn't useful, we should just collapse everything to
 IE> 'persistent'.

aside from internal implementation details, i think distinction could be a 
benefit for some advanced use cases -- some people might want to implement 
their own kind of persistent objects that is different from implementation 
of persistent-object. they can get lower level `persistent' and implement 
this as addon, without changing elephant's internals.

now, about fixes.. as i've understand we've got few enhancement 
suggestions -- Sean suggests to change names of functions, and you say the 
way shared-initialize is called should be changed. and there were 
suggestions about schema modifications..

looks like i won't be able to do all these enhancements :) (i think you or 
Sean would do it better), so for now i'll send only changes to db-postmodern 
code and my little fix for `persistent' initialization issues (unless 
somebody will submit better code by the time i'll be ready to package 
patches) -- so at least it would be passing tests with this patches. and 
latter it can be improved further..


and, by the way, a little question about shared-initialize :after thing:
some people might need to move "transient initialization" stuff from 
initialize-instance :after into shared-initialize :after. shared-initialize 
is called "more frequently" than initialize-instance -- on class 
redefinitions etc, and it has additional list of slots. i suspect in some 
cases this could lead to unexpected results.
can you formulate some guidelines about writing shared-initialize :after 
method for "transient initialization" so it won't cause confusion, or there 
are only general guidelines to implement it carefully according to 
circumstances?

fortunately pm-btree's initialization method already head checks, but 
perhaps there are more complex cases..

i think it would be nice if examples on using initialization methods would 
be included in documentation of next release