On 9/30/06, Philipp von Weitershausen <philipp@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.