Re: [Zope-dev] Re: Future of ZClasses
Andreas Jung wrote at 2006-10-9 19:24 +0200: > ... >We have some code where some classes have up to 15(!) base classes (usually >mixin classes), not counting classes inherited from the mix-in classes. I >would call that unmanageable. Each of these classes represent a mixed in feature. You get 15 classes because the end result needs a lot of features. Manageability does not increase when you implement the features differently than listing them in the inheritance clause. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
--On 9. Oktober 2006 19:11:55 +0200 Dieter Maurer <[EMAIL PROTECTED]> wrote: 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. We have some code where some classes have up to 15(!) base classes (usually mixin classes), not counting classes inherited from the mix-in classes. I would call that unmanageable. Personal productivity is one side of the medal, readability and understandability of code for other team member is the other side of the medal. Although I am not the biggest fan of the component architecture I have to admit that it makes a lot of things clearer and cleaner. -aj pgpyPNxGod5GG.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
Above all, I should mention that I believe this discussion is largely about Z3, and I do not live in Z3 world yet. Actually I am developing more in 2.7 currently. But the policy I state below is valid for 2.x also, afaik. On 10/4/06, Jean-Marc Orliaguet <[EMAIL PROTECTED]> wrote: Patrick Gerken wrote: > I think we use Interfaces in Z3 to "publish" Methods. So "maybe" it > makes sense to have a smaller core API with longer deprecation > periods, so that standard projects can try to rely on core API with > long deprecation phase and extender would use the one year deprecation > phase. But as I said earlier, I think we are quite ahead already. > > I guess the motivation of this API stability discussion is also > motivated by JMOs comment about how much more stable is the Java API, > in Point 2 and 3 of this entry: Everyone deprecates stuff, this is not the question. But what is marked as 'stable', 'official' or 'standard' may not be deprecated in the same way as something that is still under development or private. It is more a question of defining and maintaining a contract with API users than a question of technicalities (how often to deprecate, what version numbers to use, how to inform...) This is all about defining and maintaining a social contract with the user. No one prevents you from deprecating parts of an API that is marked as being "under development" or "private" -- as long as you say it from the start. Check out for instance: http://openide.netbeans.org/tutorial/api-design.html especially the chapter "Life-cycle of an API" I can see no guarantee for a time line What is unclear in zope is what is "official", what is "stable", what is still "under development", etc. It seems that all the different packages have the same status, or rather that they have no status. Apart from the packages that were added recently (zc. ...) there is no information in the repository about the quality of the different APIs. There are no version numbers on the packages either so I don't know what is alpha, beta, or final. It gives the impression that the framework is stable, but not mature. I'd expect that the API defined in the 'interfaces.py' files for instance are 'official' in the sense that there is a commitment that the API is ready and that it won't change until the next major version, but I doubt that this is understood by everyone putting stuff into these files. Deprecation can happen at any time. Anything deprecated in one release will create deprecation warnings when used for two major releases. After that the code is removed. That is the official policy. Though I believe this was never mentioned explicitly, this policy relates to the releases packaged by Andreas and Philip. So for any code released in these packages this policy is used. I BELIEVE, this is also true for all other packages on svn.zope.org Through it is unclear, which of these have stable releases. I would say that everything just in svn is unstable, and stable is, what is in the zope core packages or on cheeseshop. in Java, you can mark a class as 'final', meaning that no one will be able to subclass it, or methods can be marked as 'private'. Abstract classes can specify the methods that must be implemented. Also if a class says that it implements an interface it has to implement it otherwise the code won't compile. So here I must admit that I am from Zope2 world mostly, but some smaller Z3 code I checked actually hat assertions in their code (not in the tests directory), that checks whether its own objects really obey the interface. This is worse than in Java but shows that at least these developers were aware of these things. Sadly, except for using Meta classes I see no way to make these checks implicit like they are in Java. This is a language problem. Again this is all about defining contracts. Considering the standard JBoss modules, there is no way to compare with zope really since they strive to implement the specifications thoroughly (EJB3, JSR-168, ...) and the APIs are final already, so they don't change. Well, I can only answer with accusations like they influence the standards so much that you could already say they define the standard, and about the API I could ask how the react to changing environments, but that would not be fair, since I did not research the accusations nor how stable the API really is and what the API defines. Maybe somebody with better background can put these accusations on solid ground until then I have to believe Jean-Marc here. Anyway I appreciate your critics Jean-Marc. best regards, Patrick ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
Patrick Gerken wrote: On 10/2/06, Olavo Santos <[EMAIL PROTECTED]> wrote: Just a quick side note. Many "deprecation sign for any user" are clearly signs that Zope developers are unable to maintain certain Zope features. This is bad, specially for guys that have to manage large, complex and long time running zope installations ( think years ). And a "no sir, next app!" for guys like us who have to choose opensource development platforms for the long run ( again: think years ). Well, though nothing is perfect in Zope world, I think we are quite good in having a policy about deprecation which already gives a guaranteed timelime for deprecation. I wanted to find a deprecation policy for eclipse and JBoss to compare. For JBoss i did not find such a thing, for eclipse I did not find a eclipse framework one, but one for some sub projects: http://www.eclipse.org/webtools/adopters/#non-api-code-deprecation-policy and somehow this popped up in the eclipse search result: http://maven.apache.org/development/deprecation.html Notice especially how they mention that a deprecation phase can be days. So for me it looks we are actually a bit ahead of the competition, but maybe somebody can correct me. Accidently I lately tripped over an article from Martin Fowler about this topic: http://www.martinfowler.com/ieeeSoftware/published.pdf I think we use Interfaces in Z3 to "publish" Methods. So "maybe" it makes sense to have a smaller core API with longer deprecation periods, so that standard projects can try to rely on core API with long deprecation phase and extender would use the one year deprecation phase. But as I said earlier, I think we are quite ahead already. I guess the motivation of this API stability discussion is also motivated by JMOs comment about how much more stable is the Java API, in Point 2 and 3 of this entry: http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2006_09_23_times-they-changin But it is not fair to compare the stability of a programming language standard modules API with a application framework api. But maybe I am not good in searching and somebody points me to the well thought out JBoss or Websphere deprecation policy best regards, Patrick Everyone deprecates stuff, this is not the question. But what is marked as 'stable', 'official' or 'standard' may not be deprecated in the same way as something that is still under development or private. It is more a question of defining and maintaining a contract with API users than a question of technicalities (how often to deprecate, what version numbers to use, how to inform...) This is all about defining and maintaining a social contract with the user. No one prevents you from deprecating parts of an API that is marked as being "under development" or "private" -- as long as you say it from the start. Check out for instance: http://openide.netbeans.org/tutorial/api-design.html especially the chapter "Life-cycle of an API" What is unclear in zope is what is "official", what is "stable", what is still "under development", etc. It seems that all the different packages have the same status, or rather that they have no status. Apart from the packages that were added recently (zc. ...) there is no information in the repository about the quality of the different APIs. There are no version numbers on the packages either so I don't know what is alpha, beta, or final. It gives the impression that the framework is stable, but not mature. I'd expect that the API defined in the 'interfaces.py' files for instance are 'official' in the sense that there is a commitment that the API is ready and that it won't change until the next major version, but I doubt that this is understood by everyone putting stuff into these files. in Java, you can mark a class as 'final', meaning that no one will be able to subclass it, or methods can be marked as 'private'. Abstract classes can specify the methods that must be implemented. Also if a class says that it implements an interface it has to implement it otherwise the code won't compile. Again this is all about defining contracts. Considering the standard JBoss modules, there is no way to compare with zope really since they strive to implement the specifications thoroughly (EJB3, JSR-168, ...) and the APIs are final already, so they don't change. For other modules (e.g. Seam) users are fully aware that parts of the specs may change. For more mature modules such as Hibernate, I am not aware that the API changes between minor versions. best regards /JM ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
On 10/2/06, Olavo Santos <[EMAIL PROTECTED]> wrote: Just a quick side note. Many "deprecation sign for any user" are clearly signs that Zope developers are unable to maintain certain Zope features. This is bad, specially for guys that have to manage large, complex and long time running zope installations ( think years ). And a "no sir, next app!" for guys like us who have to choose opensource development platforms for the long run ( again: think years ). Well, though nothing is perfect in Zope world, I think we are quite good in having a policy about deprecation which already gives a guaranteed timelime for deprecation. I wanted to find a deprecation policy for eclipse and JBoss to compare. For JBoss i did not find such a thing, for eclipse I did not find a eclipse framework one, but one for some sub projects: http://www.eclipse.org/webtools/adopters/#non-api-code-deprecation-policy and somehow this popped up in the eclipse search result: http://maven.apache.org/development/deprecation.html Notice especially how they mention that a deprecation phase can be days. So for me it looks we are actually a bit ahead of the competition, but maybe somebody can correct me. Accidently I lately tripped over an article from Martin Fowler about this topic: http://www.martinfowler.com/ieeeSoftware/published.pdf I think we use Interfaces in Z3 to "publish" Methods. So "maybe" it makes sense to have a smaller core API with longer deprecation periods, so that standard projects can try to rely on core API with long deprecation phase and extender would use the one year deprecation phase. But as I said earlier, I think we are quite ahead already. I guess the motivation of this API stability discussion is also motivated by JMOs comment about how much more stable is the Java API, in Point 2 and 3 of this entry: http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2006_09_23_times-they-changin But it is not fair to compare the stability of a programming language standard modules API with a application framework api. But maybe I am not good in searching and somebody points me to the well thought out JBoss or Websphere deprecation policy best regards, Patrick ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
On 10/3/06, Dario Lopez-Kästen <[EMAIL PROTECTED]> wrote: Lennart Regebro said the following on 10/02/2006 11:16 AM: > On 10/2/06, Olavo Santos <[EMAIL PROTECTED]> wrote: >> Many "deprecation sign for any user" are clearly signs that Zope >> developers are unable to maintain certain Zope features. > > No they are not. Technically that is correct. Socially, as in "how others, eg,. mere users an developers of zope-based applications" *perceive* things, then it may very well be as Olavo S puts it. Especially when it comes to strategic decisions, eg. choosing development platform. I have no solution on how to solve this "problem", though, but I think we should be aware of it. The deprecations are indeed a sign that things are changing. This does in some way, indeed mean that the platform is unstable. Not as in "buggy", but as "rapidaly changing". Zope3 is therefore rapidly changing, and maybe even more so if you use it through Zope2 (ie Five). However, Zope2 in itself is NOT having very many deprecations, and is therefore NOT an unstable platform from this point of view. They only ones I can think of is the introduction of events instead of manage_afterAdd and such, and that is a VAST improvement over the previous situation, and backwards compatibility exist, and the much debated deprecation of zLOG. Neitehr of these were in any way a sign that anybody was unable to maintain features, and can simply not be reasonably (mis)interpreted as such. There HAVE been two signs of features not being able to be maintained, and those signs were both breakage. Breakage of ZODB version support, and breakage of ZClasses. Don't mix up deprecations with that. Deprecation are signs that things are moving fast, and is not a sign of lack of maintainance. Think of deprecations as a rerouting to another newly built road, while the lack of maintenance means that the road have holes in it. :) Too many newly build roads means drivers may get lost, and I think we ended up there in Zope3/Five, changes were too fast and too big, but done out of necessity. Zope2 has NOT experienced that. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
Lennart Regebro said the following on 10/02/2006 11:16 AM: > On 10/2/06, Olavo Santos <[EMAIL PROTECTED]> wrote: >> Many "deprecation sign for any user" are clearly signs that Zope >> developers are unable to maintain certain Zope features. > > No they are not. Technically that is correct. Socially, as in "how others, eg,. mere users an developers of zope-based applications" *perceive* things, then it may very well be as Olavo S puts it. Especially when it comes to strategic decisions, eg. choosing development platform. I have no solution on how to solve this "problem", though, but I think we should be aware of it. /dario -- -- --- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
On 10/2/06, Olavo Santos <[EMAIL PROTECTED]> wrote: Many "deprecation sign for any user" are clearly signs that Zope developers are unable to maintain certain Zope features. No they are not. AFAIK there are only two features that have fallen out of maintainability, and that's ZClasses and the Zope support for ZODB version (which is more or less useless anyway). None of these got deprecated, they just broke. Deprecation is a sign that "this feature no longer lives here, but over here instead". -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
From: "Philipp von Weitershausen" <[EMAIL PROTECTED]> Sent: Saturday, 30 de September de 2006 18:56 Hello. Also the thread that ZClass (re)distribution code will be removed need not worry you too much. Fortunately, Zope is open source and you can simply combine the new release with pieces of an older release to retain features essential to you. >>> >>> I see no problem in making the "ZClasses" a separate svn.zope.org >>> project, for example. That way they're not hindering Zope 2 core >>> releases but could still be maintained (e.g. by volunteers like >>> apparently yourself, Dieter :)) and shipped as an optional egg, for >>> example. +1 >> I think we should really make ZClasses available as separate package >> in Zope 2.11 since the current code seems to be borked for some ppl >> and because we dropped already some code (ZClasses distribution >> related staff). So moving ZClasses out of the Zope core is clear >> sign for any user: don't use ZClasses. >> >> Objections? Just a quick side note. Many "deprecation sign for any user" are clearly signs that Zope developers are unable to maintain certain Zope features. This is bad, specially for guys that have to manage large, complex and long time running zope installations ( think years ). And a "no sir, next app!" for guys like us who have to choose opensource development platforms for the long run ( again: think years ). BTW, ZClasses don't work as expected on 2.9.x. http://www.zope.org/Collectors/Zope/2005 "I'm punting to Jim, as he had better knowledge of how the persistent interfaces / specifications were supposed to work." :-) Best regards, @239, Nbk P.s. - Let's get back to zclasses -> python classes code week. %-) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
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 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. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
Philipp von Weitershausen wrote at 2006-9-30 02:30 +0200: > ... >> You want to stick this interface to individual objects, >> while Lennart proposed to stick it to a type and use >> some kind of inheritance to make it effective on all objects >> instantiated from this type. > >But where does this type come from? Persistent classes are hard (hence >ZClasses cannot be maintained by anyone except a few people). I remember that Jim proposed "PersistentModule"s, currently a ZODB proposal, to implement functionality similar to ZClasses in an easier way. But, I cannot yet answer your question sincerely. >> For me, Lennart's approach seems to be far more economic, as >> he does things on an abstract (the type) level rather than >> always work on the concrete (the individual object) level. > >I don't see how introducing another concept (a type) would be more >economic. 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. As a former mathematician, I also like the introduction of abstraction layers (object -> type/class -> metatype/metaclass -> ...) as abstraction often drastically increases economicity. >It'd be one more thing to worry about wrt persistency etc. Your answer to Lennart made me a bit unsure. It appears as if an interface could live on different abstraction levels -- at least together with ZCML and adapter magic. I am not yet really familiar with this. Let's see what Lennart answers. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
Lennart Regebro wrote: On 9/29/06, Dieter Maurer <[EMAIL PROTECTED]> wrote: You want to stick this interface to individual objects, while Lennart proposed to stick it to a type and use some kind of inheritance to make it effective on all objects instantiated from this type. For me, Lennart's approach seems to be far more economic, as he does things on an abstract (the type) level rather than always work on the concrete (the individual object) level. In fact it is absolutely necessary, as you want to be able to change the behaviour of a whole type of content classes. If you create the content class "Events" and then suddenly want all events to have a iCal export support, you do not want to enable this per event, but for the type "event". 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? The type is thusly equivalent to portal types of CMF. Types in Zope 3 are typically expressed by interfaces. I think all of your use cases can be covered with just interfaces. No need to invent yet another thing that you'll have to persist and create machinery for. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-9-29 01:35 +0200: Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-9-28 14:23 +0200: ... Why not set marker interfaces directly on the objects? That whole "type" thing is unnecessary. Just use interfaces. Usually, a type is seen as a set of objects, its type instances. It is quite nice to be able to work on a object set meta level rather than on individual objects Sure, though I don't see how an interface can't represent this meta level. Perhaps I'm missing an important point here... You want to stick this interface to individual objects, while Lennart proposed to stick it to a type and use some kind of inheritance to make it effective on all objects instantiated from this type. But where does this type come from? Persistent classes are hard (hence ZClasses cannot be maintained by anyone except a few people). For me, Lennart's approach seems to be far more economic, as he does things on an abstract (the type) level rather than always work on the concrete (the individual object) level. 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. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
On 9/29/06, Dieter Maurer <[EMAIL PROTECTED]> wrote: You want to stick this interface to individual objects, while Lennart proposed to stick it to a type and use some kind of inheritance to make it effective on all objects instantiated from this type. For me, Lennart's approach seems to be far more economic, as he does things on an abstract (the type) level rather than always work on the concrete (the individual object) level. In fact it is absolutely necessary, as you want to be able to change the behaviour of a whole type of content classes. If you create the content class "Events" and then suddenly want all events to have a iCal export support, you do not want to enable this per event, but for the type "event". The type is thusly equivalent to portal types of CMF. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
--On 29. September 2006 02:23:13 +0200 Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: Dieter Maurer wrote: Also the thread that ZClass (re)distribution code will be removed need not worry you too much. Fortunately, Zope is open source and you can simply combine the new release with pieces of an older release to retain features essential to you. I see no problem in making the "ZClasses" a separate svn.zope.org project, for example. That way they're not hindering Zope 2 core releases but could still be maintained (e.g. by volunteers like apparently yourself, Dieter :)) and shipped as an optional egg, for example. I think we should really make ZClasses available as separate package in Zope 2.11 since the current code seems to be borked for some ppl and because we dropped already some code (ZClasses distribution related staff). So moving ZClasses out of the Zope core is clear sign for any user: don't use ZClasses. Objections? Andreas pgpOeaWAhJ2JA.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
Philipp von Weitershausen wrote at 2006-9-29 01:35 +0200: >Dieter Maurer wrote: >> Philipp von Weitershausen wrote at 2006-9-28 14:23 +0200: >>> ... >>> Why not set marker interfaces directly on the objects? That whole "type" >>> thing is unnecessary. Just use interfaces. >> >> Usually, a type is seen as a set of objects, its type instances. >> >> It is quite nice to be able to work on a object set meta level >> rather than on individual objects > >Sure, though I don't see how an interface can't represent this meta >level. Perhaps I'm missing an important point here... You want to stick this interface to individual objects, while Lennart proposed to stick it to a type and use some kind of inheritance to make it effective on all objects instantiated from this type. For me, Lennart's approach seems to be far more economic, as he does things on an abstract (the type) level rather than always work on the concrete (the individual object) level. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-9-28 14:23 +0200: ... Why not set marker interfaces directly on the objects? That whole "type" thing is unnecessary. Just use interfaces. Usually, a type is seen as a set of objects, its type instances. It is quite nice to be able to work on a object set meta level rather than on individual objects Sure, though I don't see how an interface can't represent this meta level. Perhaps I'm missing an important point here... ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
Philipp von Weitershausen wrote at 2006-9-28 14:23 +0200: > ... >Why not set marker interfaces directly on the objects? That whole "type" >thing is unnecessary. Just use interfaces. Usually, a type is seen as a set of objects, its type instances. It is quite nice to be able to work on a object set meta level rather than on individual objects -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
