At 06:35 AM 8/28/2008 +0200, Michele Simionato wrote:
>Multiple inheritance of metaclasses is perhaps
>the strongest use case for multiple inheritance, but is it strong
>enough? I mean, in real code how many times did I need that?
>I would not mind make life harder for gurus and simpler for
>application programmers.
Then you need to leave MI and co-operation the hell alone. Right
now, an application programmer can mix metaclasses like this:
class FooBar(Foo, Bar):
class __metaclass__(Foo.__class__, Bar.__class__): pass
...
Or, in 3.x:
class FooBarClass(Foo.__class__, Bar.__class__): pass
class FooBar(Foo, Bar, metaclass=FooBarClass):
...
Either way, this is useful in cases where Foo and Bar come from
different frameworks. That's the *only* way to get such things to
co-operate, in fact.
>I do not think removing cooperation
>would be so bad in practice. In many practical cases, one could just write
>the metaclass by hand,
How is that making things easier for application programmers?
>Maybe you would need to duplicate a couple of lines and/or to introduce
>an helper function,
...which then has to have an agreed-upon protocol that all metaclass
authors have to follow... which we already have... but which you're
proposing to get rid of... so we can re-invent it lots of
times... in mutually incompatible ways. :)
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