[Zope3-dev] Decorators

[Steve Alexander]

Hi Sean,

Thanks for looking at this.

sean.upton@uniontrib.com wrote:
> From the draft:
> 
>>If the name is listed as one that should be decorated,
>>the attribute access is made on the mixin object 
>>instead of the inner object.
> 
> 
> Could there be a use-case for having the wrapper's name resolution check the
> inner object after checking the "attrdict" but before checking the decorator
> class?  I think I can see cases where the wrapper might be designed to add
> functionality to a bunch of objects from dumb classes, but it just might be
> the case that one of those dumb objects implements part of the decorator's
> purpose or interface (but not all).  
> 
> If the inner object has the attribute name, don't you want to favor that
> attribute (except in the case where it needs to be overridden???).  I guess
> this depends on whether the purpose of the decorator is as a supplement or
> as an alteration.

This model of decoration was meant to work much like a sort of temporary 
and localised subclassing. Normal subclassing of classes has the same 
trade-offs that you highlight above.


The news on decorators is that, after much discussion with Jim, we 
decided the work on the branch is more complicated than required for Zope 3.

I'll be reimplementing decorators more on the lines of adapters that 
individually subclass zope.proxy.context.Wrapper. Context-wrapping in 
general will be achieved by adapting from an object to IWrapper, or 
something like that.

--
Steve Alexander