[Zope-dev] Acquisition wishlist :-)

[Martijn Pieters]

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/
---------------------------------------------