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) does. 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 inheritance. 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.. From OFS.Folder:
class Folder( ObjectManager.ObjectManager, PropertyManager.PropertyManager, AccessControl.Role.RoleManager, webdav.Collection.Collection, SimpleItem.Item, FindSupport.FindSupport, ): It is in the correct order, however. Dieter