[elephant-devel] Re: fix of ele-postmodern to work withrecreate-instance-using-class
Alex Mizrahi
killerstorm at newmail.ru
Wed Jan 9 17:57:06 UTC 2008
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
More information about the elephant-devel
mailing list