[Zope-dev] Re: Future of ZClasses

[Philipp von Weitershausen]

Dieter Maurer wrote:
> Philipp von Weitershausen wrote at 2006-10-7 23:51 +0200:
>> ...
>>> I find that the introduction of classes with (multiple) inheritance
>>> has been very economic. It was another concept but a highly fruitful
>>> one, despite the fact that they are not so liked in Zope3 land.
>> I think "fat" objects from mixing many different concerns into a single 
>> implementation are a failed approach.
>>
>> Seeing how flexible you can be wit
>>
>>   a) separating concerns (functionality, responsibilities) into 
>> separate objects called components and
>>
>>   b) making the lookup of these components pluggable (using registries 
>> a.k.a. the Component Architecture),
> 
> I am almost convinced that in some years these registries
> will share the fate of acquisition: they will be seens as too much
> magic.

Perhaps. That's to be seen.

For one, the CA's registries are much less magic because look-up is 
always explicit (as opposed to the implicit acquisition as its widely 
used in Zope 2).

> I expect this to happen as soon as Zope3 is becoming main stream
> and not only used by the fittest people.

This is indeed a good point. There are currently efforts to make Zope 3 
easier for simpler use cases that wouldn't involve dealing with those 
registries, at least not directly. In fact, we're having a sprint on 
this topic this month.

>> I would not recommend anyone to over-use multiple inheritance as it's 
>> been done in Zope 2.
> 
> I am a strong favorite of (multiple) inheritance and use it excessively.
> I have the feeling that it makes me very productive.

That's good. Again, I think multiple inheritance is a valid tool. One 
reason why I would advise against using is excessively, though, is the 
lack of pluggability. The way Zope 2 deals with APIs, for example, makes 
hard to reuse and customize existing components. Sure, you CAN try to 
reuse stuff (and I know some of your tools, e.g. rebindFunction et.al. 
from ReuseUtils), but most of these revolve more around implementation 
details than around well-defined APIs and responsibilities.