[Zope-dev] Re: Future of ZClasses

[Lennart Regebro]

On 9/30/06, Philipp von Weitershausen <philipp at weitershausen.de> wrote:
> But where does this type come from? Persistent classes are hard (hence
> ZClasses cannot be maintained by anyone except a few people).

I'm hopeful that this can be solved without actually reverting to that
kind of magic.

> I don't see how introducing another concept (a type) would be more
> economic. It'd be one more thing to worry about wrt persistency etc.

Well, then we won't come further in that discussion. The type is
absolutely necessary for functionality, and as concept to make it
understandable.

> That doesn't make it necessary. Let's say all event objects are marked
> with IEvent. Now you want to add behaviour to events. You can do that by
> registering stuff for IEvent. All objects marked with IEvent will get
> the new behaviour.

> Why would a type be needed?

You are again mixing implementation details and principles. In your
example here IEvent is the type. In my first mail I was also mixing
implementation details and principles, I hope to have since rectified
that.

> Types in Zope 3 are typically expressed by interfaces.

Yes, and that would most likely be the case here too. Most likely
which "type" and object is would be expressed by letting that object
have a specific interface. This does not make "interface" and "type"
conceptually equal.

As I mentioned before, if you tell a site administrator that he can
create interfaces which enables adapters, factories and more
interfaces, he will not understand what that means, or why he would
want it or how to do it.

If you tell him that he can create types, on which he can enable
functionality and create views and pages, than he will understand.

We can't call everything "interfaces", no matter how we use them and
expect people to understand us.