Martijn Pieters writes:
> > It would be much clearer, when "Item" could declare,
> > it does not want to acquire the methods without
> > providing a definition.
> And then inherit the fact that your parent class doesn't acquire? You
> always have to pay attention to what order you use when subclassing
> anyway, this doesn't change that. If you want one subclass to have
> presedence over another, change the order in which you inherit.
There are two things here:
1. I, and many other Zope users, do not expect DocumentTemplate
and friends to define "objectValues" and friends.
They are not ObjectManagers, and therefore should not
define these methods.
If they neverthless need to do, then this indicates a weakness.
In this case, a weakness with "Acquisition".
2. Zope has similar inheritance questions with respect
to permission inheritance and solved it quite well.
I think, this is what the "default_callinit" (or so)
If there is a chance, that Acquisition is extended
(what I doubt), then I will think about a good
proposal how "don't acquire" should work with
My feeling (without much thought) goes towards the following aims:
* acquisition declarations should not interfere
with the objects own infrastructure (attributes, methods).
This is consistent with the effect of acquisition
to provide a value for a name only, if the object does not
have this name itself.
* their should probably both positive
and negative acquisition declarations
("I do want to acquire" and "I do not want to acquire").
If there are conflicting declarations for a name,
the inheritance order decides.
> Just a pedantic technical sidenote; you'll never have to combine
> ObjectManager and SimpleItem.Item, the two classes are like the two poles
> of a magnet..
It is in the correct order, however.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -