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

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 from ReuseUtils), but most of these revolve more around implementation details than around well-defined APIs and responsibilities.
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to