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