Why are ZClasses bad?
Hello! I keep hearing people argue that ZClasse are bad, and I am curious as to why they are. I recall something about ZClasses and the catalog, but are there any other "badness" with ZClasses? /dario - curious - -------------------------------------------------------------------- Dario Lopez-Kästen, dario@ita.chalmers.se IT Systems & Services System Developer/System Administrator Chalmers University of Tech.
Hi! I guess ZClasses are not "evil" or so. But as somebody who has worked with ZClasses for a long time and then switched to Python Products instead, I see a lot of problems/disadvantages ZClasses have: - Most important: It is rather hard to change the base classes with ZClasses. In Python, you can do that very easily. - Copy&paste programming does not work with ZClasses. With Python Products, I can start writing my own version of an existing Product by just searching and replacing all the occurences of the original Product name by my own one. With ZClasses, copying an existing ZClass and changing it to fit will not work well. - If you use a decent editor (I am currently using PythonWin on Windows), it is much more convenient to have all the methods of your class in just one file than having to drill down into the ZMI and search for individual Scripts (Python) or DTML Methods - Debugging Python code is easier than debugging ZClasses. E.g., you can use a real debugger, or just add temporary print statements to the code. With Python code, the tracebacks are much more helpful than they are with ZClasses, especially if you use DTML ... - Working from Python gives you MUCH more power, and the code usually is more compact. - You can use CVS for the code, and there is a rather strict separation between instances of your Product/class and the code ... - ZClasses behave "strange" with regard to nested acquisition. I experienced cases where two instances of a ZClass acquired from each other in a way they shouldn't ... - ZClasses are relatively slow, especially if you use other ZClasses as base classes of ZClasses. One of the great disadvantages of Python-based Products was that you had to permanently restart your Zope to see the changes in action. But now we have "refresh", which works great. That said, I can still imagine using ZClasses together with a custom-built Python-based base class. They are over-the-web, which is their greatest advantage. For Zope 3, I'd suggest a complete redesign of ZClasses to offer something similar without the disadvantages ... ----- Original Message ----- From: "Dario Lopez-Kästen" <dario@ita.chalmers.se> To: <zope-dev@zope.org> Sent: Wednesday, April 03, 2002 11:20 AM Subject: [Zope-dev] Why are ZClasses bad? Hello! I keep hearing people argue that ZClasse are bad, and I am curious as to why they are. I recall something about ZClasses and the catalog, but are there any other "badness" with ZClasses? /dario - curious - -------------------------------------------------------------------- Dario Lopez-Kästen, dario@ita.chalmers.se IT Systems & Services System Developer/System Administrator Chalmers University of Tech. _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
On Wed, 3 Apr 2002 11:40:36 +0200, "Joachim Werner" <joe@iuveno-net.de> wrote:
Hi!
I agree with most of what was said before, but have a few things to add....
- Most important: It is rather hard to change the base classes with ZClasses. In Python, you can do that very easily.
Or you can adopt a design rule that you should write a simple Python base class for every ZClass, and put your *real* base classes there. This makes it easy to change base classes later, and makes it easy to add a pure python method too. The main disadvantage to this ZClass/Product hybrid comes from distribution. It works great only if you are not planning to distribute the Product (or, pair of Products ;-) Toby Dickenson tdickenson@geminidataloggers.com
participants (3)
-
Dario Lopez-Kästen -
Joachim Werner -
Toby Dickenson