On 9/30/06, Philipp von Weitershausen <[EMAIL PROTECTED]> 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

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

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.
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to