Re: [Zope-dev] Acquisition wishlist :-)
Chris Withers writes:
And I suppose the other part of my wishlist:
class MyClass(Acquisition.Implicit): # your_attribute will be acquied
# index_html won't index_html = None No, that is not enough!
As a side effect to turn off acquisition, you defined the attribute. This will not play well with inheritance: You will not only prevent acquisition of "index_html" but also prevent inheritance of it (which may be really necessary in some contexts). Dieter
Dieter Maurer wrote:
Chris Withers writes:
And I suppose the other part of my wishlist:
class MyClass(Acquisition.Implicit): # your_attribute will be acquied
# index_html won't index_html = None No, that is not enough!
As a side effect to turn off acquisition, you defined the attribute. This will not play well with inheritance: You will not only prevent acquisition of "index_html" but also prevent inheritance of it (which may be really necessary in some contexts).
I'm pretty sure inheritence takes precedence over Acquisition. You wouldn't need to have index_html = None if it is inherited, since the inherited idnex_html would be used before one is acquired, surely? cheers, Chris
On Mon, Jan 08, 2001 at 10:10:34AM +0000, Chris Withers wrote:
Dieter Maurer wrote:
Chris Withers writes:
And I suppose the other part of my wishlist:
class MyClass(Acquisition.Implicit): # your_attribute will be acquied
# index_html won't index_html = None No, that is not enough!
As a side effect to turn off acquisition, you defined the attribute. This will not play well with inheritance: You will not only prevent acquisition of "index_html" but also prevent inheritance of it (which may be really necessary in some contexts).
I'm pretty sure inheritence takes precedence over Acquisition.
You wouldn't need to have index_html = None if it is inherited, since the inherited idnex_html would be used before one is acquired, surely?
Yup. If you don't want to have any index_html *at all*, just declare it index_html = None. DTML Methods and HiperDom templates do this as well, for example. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------
Martijn Pieters writes:
On Mon, Jan 08, 2001 at 10:10:34AM +0000, Chris Withers wrote:
You wouldn't need to have index_html = None if it is inherited, since the inherited idnex_html would be used before one is acquired, surely?
Yup. If you don't want to have any index_html *at all*, just declare it index_html = None. DTML Methods and HiperDom templates do this as well, for example. You have an "index_html" and its value is "None".
If you use this class with another class that has a useful "index_html", you must care for the inheritance order to get the right on. Dieter
On Mon, Jan 08, 2001 at 10:38:22PM +0100, Dieter Maurer wrote:
Martijn Pieters writes:
On Mon, Jan 08, 2001 at 10:10:34AM +0000, Chris Withers wrote:
You wouldn't need to have index_html = None if it is inherited, since the inherited idnex_html would be used before one is acquired, surely?
Yup. If you don't want to have any index_html *at all*, just declare it index_html = None. DTML Methods and HiperDom templates do this as well, for example. You have an "index_html" and its value is "None".
If you use this class with another class that has a useful "index_html", you must care for the inheritance order to get the right on.
Of course, but you always have to. index_html in any class could be anything. You could even override the inherited 'index_html = None' with 'index_html = Acquisition.Acquire'. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------
Chris Withers writes:
Dieter Maurer wrote:
Chris Withers writes:
And I suppose the other part of my wishlist:
class MyClass(Acquisition.Implicit): # your_attribute will be acquied
# index_html won't index_html = None No, that is not enough!
As a side effect to turn off acquisition, you defined the attribute. This will not play well with inheritance: You will not only prevent acquisition of "index_html" but also prevent inheritance of it (which may be really necessary in some contexts).
I'm pretty sure inheritence takes precedence over Acquisition.
You wouldn't need to have index_html = None if it is inherited, since the inherited idnex_html would be used before one is acquired, surely? Of cause, but that's unfortunately only a local view.
In Python (and Zope) you have multiple inheritance and mixin classes. You do not know with what classes you (or someone else) will combine a class at hand. If it is good in one context to disable acquisition for a method because the class does not provide a usefull definition but still does not want to inherit it, then in a different context, the method should be provided by an inherited class. A good example is "objectValues" and friends. "SimpleItem.Item" defines them to return empty tuples (to prevent acquisition from the containing container), but if you combine a class derived from "SimpleItem.Item" with an ObjectManager, you want the ObjectManager's "objectValues" and not that stupid method from "Item". It would be much clearer, when "Item" could declare, it does not want to acquire the methods without providing a definition. Dieter
Dieter Maurer wrote:
<snip example>
It would be much clearer, when "Item" could declare, it does not want to acquire the methods without providing a definition.
Having seen the example, I think you're right :-) cheers, Chris
On Mon, Jan 08, 2001 at 10:26:25PM +0100, Dieter Maurer wrote:
Chris Withers writes:
Dieter Maurer wrote:
Chris Withers writes:
And I suppose the other part of my wishlist:
class MyClass(Acquisition.Implicit): # your_attribute will be acquied
# index_html won't index_html = None No, that is not enough!
As a side effect to turn off acquisition, you defined the attribute. This will not play well with inheritance: You will not only prevent acquisition of "index_html" but also prevent inheritance of it (which may be really necessary in some contexts).
I'm pretty sure inheritence takes precedence over Acquisition.
You wouldn't need to have index_html = None if it is inherited, since the inherited idnex_html would be used before one is acquired, surely? Of cause, but that's unfortunately only a local view.
In Python (and Zope) you have multiple inheritance and mixin classes. You do not know with what classes you (or someone else) will combine a class at hand. If it is good in one context to disable acquisition for a method because the class does not provide a usefull definition but still does not want to inherit it, then in a different context, the method should be provided by an inherited class.
A good example is "objectValues" and friends. "SimpleItem.Item" defines them to return empty tuples (to prevent acquisition from the containing container), but if you combine a class derived from "SimpleItem.Item" with an ObjectManager, you want the ObjectManager's "objectValues" and not that stupid method from "Item".
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. 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.. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------
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
participants (3)
-
Chris Withers -
Dieter Maurer -
Martijn Pieters