decorators as generalized pre-binding hooks

[Kay Schluehr]

George Sakkis schrieb:

> > 1. classes have metaclasses, functions don't have metafunctions.  No one
> > gave an example for classes not handled at least as well with a metaclass.
>
> Would something like the following count ?
>
> @abstractclass
> class AbstractFrame(object):
>
>     @abstractclass
>     @innerclass
>     class AbstractPanel(object):
>         pass
>
> For one thing, it's more readable than the respective __metaclass__
> declarations. Moreover, stacking two or more decorators is
> syntactically straightforward, while for metaclasses you have to write
> boilerplate code for making a subclass of the components, e.g.:
> class AbstractInnerClass(AbstractClass, InnerClass): pass
> Fortunately metaclasses are not that commonly used to cause
> combinatorial explosion of such boilerplate classes.

I think it would be a good idea to pronounce the similarity between
function decorators and metaclasses. Metaclasses were once introduced
as an arcane art of fuzzy bearded hackers or supersmart 'enterprise
architects' that plan at least products of Zope size but not as a tool
for the simple programmer on the street. But maybe they should be and
there should also be librarys of them representing orthogonal
customizations ready for plug in.

Since metaclasses follow an "adapt", "customize" or "decorate"
semantics it is a good idea not to use inheritance to stack them which
implies that one metaclass refines an other.

+1 for metaclasses as class decorators.

Kay