On Fri, 2002-05-31 at 15:14, Toby Dickenson wrote:
> On Friday 31 May 2002 4:44 am, Tim Hoffman wrote:
> > But whilst you might think acquisition looks like inheritance it isn't
> > Please don't confuse the two, they really are different, and until
> > you think about them differently, I believe you won't necessarily
> > grasp the significance of acquisition, or use it properly.
> Agreed.
> > Any tool/language/approach/methodology can be used incorrectly,
> But today implicit acquisition is forced onto almost every zope class, and 
> every attribute lookup. Sometimes the way to use acquisition correctly is not 
> to use it at all, but that is often an impossible option. These 
> characteristics mean implicit acquisition is not a "tool" - its a disease.
True, however all of my work to date in CMF, I haven't found that
acquisition, to be a major problem, except once. 

However the most problems I have had, are with poorly thought out or
poorly documented object hierarchies, 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 ;-)

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.

(I think we will be in a much better position with Zope 3)

Also if it doesn't work the way it is documented you could call it a
bug, whereas the current situation is hmm is this how it work or is it a
bug, or am I missing something  ;-)



> Imagine if you couldnt write a C++ class without including operator 
> overloading functions......
I hate C++ ;-) 

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to