[Zope3-dev] A generic Decorator class

[Steve Alexander]

On Wed, 20 Feb 2002, Martijn Faassen wrote:

> Steve Alexander wrote:
>
> I think this kind of technique can be useful, though it can get very
> messy as you run into namespace spillover issues if you aren't careful
> ('where's this method coming from' becomes more difficult). Another caveat
> that if used a lot it can slow things down a lot.

That's a good point. However, I'm only "acquiring" methods that come from
particular interfaces of a decorating object, so things should be much
clearer than when using forms of acquisition where everything gets
acquired.

In my next iteration of Decorator.py, I'll make the choice of interfaces
entirely explicit.

> Note also that one can use acquisition to accomplish this kind of layering
> as well, which is more efficient, though has some other issues (if you're
> depending on acquisition hierarchy in code you screw it up by adding
> unexpected objects like this).

The code that's in my Chapter 1, Step 6 tarball adds the Decorator object
to the current ContextWrapper. That's important to play nicely with Zope
3's security system.

Other than that, I'm using Python 2.2's __getattribute__, which is the
same as how the Python version of Persistence works in Zope 3, and how I
would expect the Zope 3 version of acqisition will work. So, my approach
should be roughly as quick as using acquisition, provided I optimise the
lookup of interfaces in some way.

--
Steve Alexander