On Thu, Aug 28, 2008 at 8:54 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> I created a "universal metaclass" in
> DecoratorTools whose sole function is to delegate metaclass __new__,
> __init__, and __call__ to class-level methods (e.g. __class_new__,
> __class_call__, etc.), thereby eliminating the need to have custom
> metaclasses for most use cases in the first place. Now, wherever possible,
> I use that single metaclass in my frameworks, so that there's no need to mix
> them.
easy_installed DecoratorTools and found it: classy_class.
>From the point of view of the code, this is a beautiful and elegant
snippet. However, suppose that from tomorrow everybody starts
using it. Since metaclasses would become so easy to use, possibly a
lot of people would take advantage of them. Then we would have
potentially complex (multiple) inheritance hierarchies with
chains of methods (_class__new__/_class__init__) calling
themselves cooperatively in the MRO. Would the resulting
code be readable? How easy would be for an average framework user
to understand what is happening to his class?
I think class decorators would be a much better solution than
classy_class for most use cases and we should push that way,
not the cooperative inheritance way.
Generally speaking I like
more solutions bases on functional composition (as in WSGI
that you know very well) than on method cooperation. Rather than
improve the support for inheritance, I would like (in an ideal
world) to reduce it, to make easier the choice for people between
inheritance and alternatives (object composition, delegation, functional
composition). In the real world, I am content in documenting the
pitfalls of super, warn people about the dangers of complex
design involving multiple inheritance and cooperation, and suggest
alternatives.
Michele Simionato
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4