[Zope3-dev] Allowing views to be registered for classes ratherthaninterfaces.

[Steve Alexander]

> As a third party developer, I really don't care where my superclasses
> are located. Why is this an issue for zope development? (I might be
> missing your point.)

One of the big problems developing for Zope 2 is that there are lots of 
mix-in classes and base classes that are pretty much required.

The dependencies among mix-ins and base classes are more difficult to 
document and understand than the dependencies between separate 
components that are described by interfaces.

I do care where my superclasses are located. I usually find that I need 
to read their code to understand what I need to do in my subclass.

That's one reason why I prefer to avoid subclassing where possible.


In Zope 3, we don't require any mix-in classes or base classes. This 
non-requirement was motivated by the experience with Zope 2.

However, we do still use base-classes and mix-ins to make hierarchies of 
interfaces, and also to reuse functionality in related implementations.

As to my point... I don't find it a problem to find the interfaces for 
an implementation or to find the implementation for a view. Then again, 
I do know the code quite well, so I might not represent the typical case.

I find the comparable situation with subclasses much more difficult.


> I'm not arguing that implementations are *not* related by subclass
> relationships. I'm arguing that something like i18nfile and workflow
> 'projects' are units whose internal relationships are *stronger than*
> their respective relationships to superclasses.

Ok. Now that we understand the contents of zope.app somewhat better, 
perhaps it is time to think about breaking it up into smaller conceptual 
projects.

I see you've discussed this a bit in another email.

--
Steve Alexander