[Zope-dev] Re: Zope logic

[Tim Hoffman]

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
> 
> 
>