[Zope3-dev] A generic Decorator class

[Steve Alexander]

Gary Poster wrote:
> From: "Steve Alexander" <steve@cat-box.net>
> 
>>---- obligatory GOF quote ----
>>Decorator (p.175):
>>
>>   Attach additional responsibilities to an object dynamically.
>>Decorators provide a flexible alternative to subclassing for extending
>>functionality.
>>----                      ----
>>
> 
> OK, forgive the guy who hasn't coded in Zope 3 yet.  This is an "edify me"
> request.

Please do go through the Python Programmer Tutorial that is in CVS. Run 
Zope3, stick a few contacts in a folder, view them and edit them.

Also, take a look at the extra Step 6 I just uploaded to my website (see 
  the message I posted about 5 minutes ago).

I can answer questions about the tutorial when I've got time.

Please do get a recent checkout of the tutorial. I corrected a couple of 
typos in the code and the configuration file which can make things break 
in a confusing way. These corrections were checked in yesterday or Friday.


> Studying GoF in the past, I thought acquisition was the preferred
> Zope/Python implementation of this pattern.  All the GoF decorator does is
> wrap the original object to give it new functionality: e.g. (I thought)
> implicit acquisition.  Then the object can in fact announce what interfaces
> it provides, through acquisition.  I remember being pretty impressed at how
> thorough a job acquisition did at implementing this pattern.
> 
> I know Zope 3 is moving over to explicit for default behavior, but that
> doesn't mean to me that, when implicit makes sense, you don't use implicit.

Well, it turns out that my Decorator class does pretty much the same job 
as a little bit of acquisition would do here.

Even if I implemented Decorator using the acquisition libraries, I'd 
still want to have a class called Decorator hiding the implementation. 
What's important is that I'm decorating an IContactInfo object with some 
related IPostalInfo functionality. It shouldn't matter exactly how I do 
that, to the component that uses a Decorator.


> So, why is another Decorator pattern necessary?  Is implicit acquisition
> just frowned upon so much now, as a potentially confusing implementation,
> that another approach is needed?  Or is acquisition already fulfilling
> another role in this module that makes it difficult or impossible to use it
> for this purpose as well?  Or do I not get something basic?

I think you've got the right idea. You're asking "why reinvent the 
wheel?" I'm answering "because I've got a flywheel, but I want a 
steering-wheel". Or something like that.

You can use a flywheel as a steering-wheel, but you'd want to wrap it in 
  something to make it easy to grab hold of.

--
Steve Alexander