Hi 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 ;-) Rgds Tim
Imagine if you couldnt write a C++ class without including operator overloading functions...... I hate C++ ;-)