[Zope-dev] Re: Future of ZClasses
Philipp von Weitershausen wrote at 2006-10-7 23:51 +0200: ... 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. I think fat objects from mixing many different concerns into a single implementation are a failed approach. Seeing how flexible you can be wit a) separating concerns (functionality, responsibilities) into separate objects called components and b) making the lookup of these components pluggable (using registries a.k.a. the Component Architecture), I am almost convinced that in some years these registries will share the fate of acquisition: they will be seens as too much magic. I expect this to happen as soon as Zope3 is becoming main stream and not only used by the fittest people. 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. -- 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 )
Fat vs Greasy (Was: [Zope-dev] Re: Future of ZClasses)
On 10/9/06, Dieter Maurer [EMAIL PROTECTED] wrote: Philipp von Weitershausen wrote at 2006-10-7 23:51 +0200: ... 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. I think fat objects from mixing many different concerns into a single implementation are a failed approach. Seeing how flexible you can be wit a) separating concerns (functionality, responsibilities) into separate objects called components and b) making the lookup of these components pluggable (using registries a.k.a. the Component Architecture), I am almost convinced that in some years these registries will share the fate of acquisition: they will be seens as too much magic. I expect this to happen as soon as Zope3 is becoming main stream and not only used by the fittest people. 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. There is of course no conflict between the two attitudes. It may *look* like there is, though. ;) In one case, you make loads of small objects with separate concerns, and merge them into one object by multiple-inheritance. In the other case you make loads of small objects with separate concerns and merge them via adapters. The first version is less flexible, as changing the behaviour of the resulting fat objects requires subclassing, while the other attitude can be hard to overview and grasp (and hence, I'll call it greasy. Haha.) I think one generally should, in Zope3/Five, use objects as if they always need to be adapted. That is, you get the context, and you adapt it to whatever interface you need, with IMyinterface(context). Then, of course, you may very well make your object a fat object that implement all the bloody interfaces you need, instead of having multiple sets of objects and adapters, which in most cases just make things complicated. But with this attitde, that is make fat objects, but never assume they are fat when you use them, you can with little effort make something flexible. For example: The CalZope calendar attaches all views directly to the ICalendar interface. Only ICalendar objects can have these views. A calendar object in CPS is therefore a calendar that directly implements ICalendar, and some other extended interfaces with CPS support and stuff. This seems perfectly reaonable, but it turns out Plone people don't want that. They want ordinary folder to have these views. The solution to that is to attach all the views to ICalendarViewable and in all views make self.context = ICalendar(context), and this way adapt the context. By making my fat calendar objects IcalendarViewable, I need not to change any other code in CPSSharedCalendar or CalZope. I still have the same monolithic objects, that are easy to understand and debug. But for Plone, it would with these changes be perfectly possible to make adapters from Plone folders to ICalendar, and therefore use CalZope views for folders full of plone events. So, as long as you *use* the objects as if they always need to be adapted, you can very well write the objects monolithically if that suits you. So, heres a new tagline: Use your objects as if they were greasy, and it isn't a problem if they are fat. ;-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.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 )
[Zope-dev] Re: Future of ZClasses
Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-10-7 23:51 +0200: ... 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. I think fat objects from mixing many different concerns into a single implementation are a failed approach. Seeing how flexible you can be wit a) separating concerns (functionality, responsibilities) into separate objects called components and b) making the lookup of these components pluggable (using registries a.k.a. the Component Architecture), I am almost convinced that in some years these registries will share the fate of acquisition: they will be seens as too much magic. Perhaps. That's to be seen. For one, the CA's registries are much less magic because look-up is always explicit (as opposed to the implicit acquisition as its widely used in Zope 2). I expect this to happen as soon as Zope3 is becoming main stream and not only used by the fittest people. This is indeed a good point. There are currently efforts to make Zope 3 easier for simpler use cases that wouldn't involve dealing with those registries, at least not directly. In fact, we're having a sprint on this topic this month. 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. That's good. Again, I think multiple inheritance is a valid tool. One reason why I would advise against using is excessively, though, is the lack of pluggability. The way Zope 2 deals with APIs, for example, makes hard to reuse and customize existing components. Sure, you CAN try to reuse stuff (and I know some of your tools, e.g. rebindFunction et.al. from ReuseUtils), but most of these revolve more around implementation details than around well-defined APIs and responsibilities. ___ 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
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 )
[Zope-dev] Re: Future of ZClasses
Philipp von Weitershausen wrote at 2006-10-9 19:59 +0200: ... Sure, you CAN try to reuse stuff (and I know some of your tools, e.g. rebindFunction et.al. from ReuseUtils), but most of these revolve more around implementation details than around well-defined APIs and responsibilities. This must mean most of those you know of and not most of my tools :-) -- 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: Fat vs Greasy (Was: [Zope-dev] Re: Future of ZClasses)
On 10/9/06, Jean-Marc Orliaguet [EMAIL PROTECTED] wrote: That's basically what I wrote the other day (The Times... ) : as an application designer you want a *plugin architecture* with greasy fat components, not an architecture with hundreds of micro-components wired together like this: http://jacobswellchurch.org/tim/archives/wires-bottom.jpg that require that learn the internals. Also, plugin logic is not the same as micro-component logic: - plugins are single units that only need a runtime platform to get working, while micro-components need to get assembled before they can be used, the border between the platform and the platform's components is very blurry. - plugins have a public API that preserves backward compatibility, and hence preserves user's investments, while micro-components neither have a public or private API, they implement interfaces (interface != API) - plugins can get loaded and unloaded at runtime, or updated, while micro-components are basically added once at server startup time and they never get changed at run-time. - a plugin architecture can manage dependencies between plugins. - plugins are useful to market an architecture, (cf. Photoshop gimp, Gimp plugins, VDR plugins (http://www.cadsoft.de/vdr/plugins.htm), Firefox plugins, skins, Azureus plugins, Eclipse plugins ...). It is easy to explain what a plugin does in terms of functionality, while it is difficult to explain what a micro-component does. //- plugins encourage participation!!! (that's one of the reason of the success of Plone IMO: every one feel that they can create their own product, by looking at other existing products), while micro-components are difficult to grasp. - plugins can be used by end-users, while micro-components are designed by developers for developers. That's not at all what I said. ;) But you have valid points and I basically agree with your separations of micro-components and plugins. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.nuxeo.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 )
[Zope-dev] Re: Future of ZClasses
Lennart Regebro wrote: 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. Ok, sure. Then we agree. The 'type' would be a special kind of interface. It's a concept, rather than an implementation detail (e.g. like 'view' is an adapter). ___ 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 )
[Zope-dev] Re: Future of ZClasses
Dieter Maurer wrote: 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 PersistentModules, currently a ZODB proposal, to implement functionality similar to ZClasses in an easier way. But, I cannot yet answer your question sincerely. I can't either. If we ever get persistent code, that's nice, but I'd still be skeptical. Frankly, I think it's yagni (you ain't gonna need it). And if I understood Jim correctly, he nowadays prefers the code is on the filesystem and we evolve datastructures using generations story over code and datastructures are persistent so that both can be evolved at the same time. 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. I think fat objects from mixing many different concerns into a single implementation are a failed approach. Seeing how flexible you can be wit a) separating concerns (functionality, responsibilities) into separate objects called components and b) making the lookup of these components pluggable (using registries a.k.a. the Component Architecture), I would not recommend anyone to over-use multiple inheritance as it's been done in Zope 2. That is not to say that inheritance and even multiple inheritance is evil. I think the right balance is necessary :) ___ 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
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
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
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/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
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 )
[Zope-dev] Re: Future of ZClasses
Andreas Jung wrote: --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? None from me. We just need to be careful about the rest of Zope. It may depend on ZClasses (e.g. notifying them when new disk products are there, etc.). That needs to be decoupled (perhaps using events?) Philipp ___ 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
--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
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
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
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
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 PersistentModules, 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 )
[Zope-dev] Re: Future of ZClasses
Lennart Regebro wrote: On 9/27/06, Andreas Jung [EMAIL PROTECTED] wrote: It's definitely time to work on a replacement. Yes. And here is my short vision of that. Comments are appreciated. Have you looked at zope.app.schemacontent, Sidnei's prototype for TTW-schemas and content based on that? 1. We have a base content class used to create content objects. This has the concept of type, pretty much like CMFs portal_type. The type is defined in the ZODB. Possibly. It's important to keep this content class really really dull (one size fits all) so that we don't need to magically create persistent classes or something. 2. On the type you can set marker interfaces, Why not set marker interfaces directly on the objects? That whole type thing is unnecessary. Just use interfaces. that enables adapters with different functionality, such as indexing awareness, and whatnot. Yes and no. catlaog awareness is a Zope 2 thing, with the CA you'd use events. These adapters are written in diskbased pythons. Hence any type of basic functionality like this still needs to be disk-based. Except for views, perhaps. Simple template-based views could still be done through-the-web, perhaps even views that are implemented as Python Scripts. 3. Each type also has schemas Type, schema, and interfaces should be synonymous: interfaces. Don't invent more concepts than we already have. and forms, those can be automated from the schema 4. When you then run into a thing you can't do through the web you are not stuck. Wrong. You write it in Python and register it locally for your type (read: interface). If you want to add new event handler for your type, you can write a new functionality adapter on disk, and then enable it via marker interfces for your type. No need for the marker interface. You already have your type interface. Just use that. If you python scripts security becomes a hindrance, you can easily move that to disk by making another marker interface and building views for that. We could even have a button Export to disk module which exports the current templates + scripts to a view + methods + templates all on disk. This combines and easy plug-and-play attitude with TTW programming without providing a dead end. Hopefully. So, when are you going to write it? :) ___ 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 )
[Zope-dev] Re: Future of ZClasses
Thanks for the comments. For all the things you wrote that I deleted, I would just say Exactly! :-) Here are the things that are not exactly!: On 9/28/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Have you looked at zope.app.schemacontent, Sidnei's prototype for TTW-schemas and content based on that? Nope. But thanks for the hint. 2. On the type you can set marker interfaces, Why not set marker interfaces directly on the objects? That whole type thing is unnecessary. Just use interfaces. Because you want to be able to add a new functionality (by setting a new marker interface on the type), and get it added to all the objects that have that type. Of course, the type assignment would, I expect, in itself be done by a marker interface, but that's implementation details I don't want to think about yet. :-) I was unfortunately talking too much implementation details. I should have tried to be more conceptual. From now on, I will call the functionality adapters for aspects. :) that enables adapters with different functionality, such as indexing awareness, and whatnot. Yes and no. catlaog awareness is a Zope 2 thing, with the CA you'd use events. Well, that was the one example I could think of just then, although I knew it was a crap one. I could think of specialized aspects, such as an aspect to automatically ping a site like del.icio.us when you post your bloggentry, but I couldn't think of anything truly generic. However, during this answer, I did think of something better: Workflows: You could for example have an aspect for a simple publishing workflow. So if you enable this, the objects of the type gets a publishing workflow. And another aspect could enable the wmfc workflow module for the object, for example. (Which makes me realize that some aspects could need settings on the type... Hmmm...) 3. Each type also has schemas Type, schema, and interfaces should be synonymous: interfaces. Don't invent more concepts than we already have. Nah, they should not be synonyms. But I was as mentioned mixing implementation and concepts before. I'll explain: The people who use these new ZClasses want to be able to create content types that has forms with a set of fields and informations like if a field should be required or max length and stuff. They also want to be able to create specialized views, and enable aspects for the type, like saying that objects of this type should have this workflow. They will never understand you if you call both the forms, and the views and the aspects for interfaces, because although technically there are interfaces below all of this, the functionality in the end is wildly different, and the way you use it is also wildly different. How all this is implemented and attached to the object is nothing the user want to be aware of. However, you may be right in that maybe one schema, and a set of views, in themselves should be an aspect, so that you do not assign these to types, but you create a form-aspect and a view-aspect, and assign these to the type. 4. When you then run into a thing you can't do through the web you are not stuck. Wrong. You write it in Python and register it locally for your type (read: interface). I think you missed a not there. :) If you want to add new event handler for your type, you can write a new functionality adapter on disk, and then enable it via marker interfces for your type. No need for the marker interface. You already have your type interface. Just use that. Yes, and no. If I do that, I can't use the aspect for other types. Then I'm stuck with using it ONLY for that type. This may be what I want, or it may not be. So, when are you going to write it? :) My crystal ball blue-screened. :-) -- 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
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 )
[Zope-dev] Re: Future of ZClasses
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 don't see ZClasses as anything particular evil or good, just having them languish in the Zope 2 core puts a burden on all those who don't understand them and don't have the bandwidth to support them. So it's not about being overly eager regarding removal, it's about risk management for future releases. Moving ZClasses to a separate project reduces the risk of the Zope 2 core. Like you said, even you can't promise to keep ZClasses working for every Zope release... We have a large ZClass based application. And I will keep it working. Great! ___ 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 )
[Zope-dev] Re: Future of ZClasses
Andreas Jung skrev: --On 27. September 2006 13:47:26 -0400 Jonathan [EMAIL PROTECTED] wrote: ... i don't suppose anyone has an 'automagical' utility that instantly transforms zclasses to python classes, and then changes all dtml/external method usage do they? ...didn't think so ;-) Also I don't think so. Just my personal opinion: ZClasses were the biggest mistake in the history of Zope :-) Only the implementation. The idea of interactively creating objects through the web is a brilliant idea. ___ 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 )
