Hi On Fri, 2002-05-31 at 16:10, Steve Alexander wrote:
Tim Hoffman wrote:
However the most problems I have had, are with poorly thought out or poorly documented object hierarchies,
You mean "class hierarchies".
Oops, yep, that's what I meant,
so that it is not obvious or clear where and when you should override methods, try "manage_afterClone" some time, and I know this isn't an acquisition problem, or overriding some of the default behaviour for FTP methods. The lack of documented approach is far worse than the enforced acquisition, IMHO ;-)
You'll like Zope3 then. There is no dependency on class hierarchies. The inheritance hierarchies throughout are either very shallow or non-existent.
However, none of the power of expressing the affordances of objects is lost. Instead, this is expressed through the interfaces an object implements, which can be definied either in your class definitions, or elsewhere in zcml or in other classes/interfaces.
Yeah, I have been following most of the Zope3 discussions.
If how these things work and how to use them, was well documented, then strangeness with acquisition wouldn't be so strange, ie it would be documented and you could get your head around it.
There is only so much complexity that I can handle at a time. Often working on what should be an isolated part of Zope2 exceeds that threshold.
Tell me about it, I really can't do much without keeping an IDLE session going and trolling through all the source, try getting immutable unique ID's working for every object in a CMF site, that when you clone an object you get a new unique ID, man I had some trouble with that, it seemed where manage_afterClone changed in a release or two, so that things stopped working, after an upgrade. Having clearly defined public interfaces will certainly help. See ya T
(I think we will be in a much better position with Zope 3)
:-)
-- Steve Alexander