Can I, a humble Zope product developer, please make a plea that anything "marked as an 'official evil'" be made as invisible as possible? (I.e. that you make it disappear unless specifically configured as an option, as was suggested up-thread).
Zope is already full of deprecated methods that make learning the "one obvious way to do it" very hard to figure out. The refrain on the ML and in other places is "if the documentation isn't good enough, 'use the Source, Luke'", but have you actually looked at the source? Sorry, I know you have -- but please try to imagine what it looks like to a newcomer who doesn't know their way around like you do. We already have same-named objects defined in multiple places -- are they really all the same object? Are they different implementations of the same object? Are they actually just imports from one module to another? Are they overloaded with additional functionality? Also lots of similar objects -- should I use "Item" or "SimpleItem". Should I inherit stuff from "Globals" or from the files they are actually defined in? It is an important point of information architecture that signs to the user must be graded in order to be most useful -- many signs with the same apparent importance are confusing, and may be worse than no signs at all. Also, whereas you, who are intimately familiar with evolutionary history of Zope's source may be completely aware of what's old and what's new, the newbie developer has little way to determine this. I can look at file dates, and occasionally I can find notes explaining this in the comments. But too often developers say something along the lines of "this is the new improved way to do X". But when did they write that? Last month? A year ago? Longer? I recognize that you all have made steps in this direction for Zope 3 (such as the interface/components concept, which IMHO is a big improvement). Reducing confusion should be a big priority, I hope. And what you don't say is just as good as what you do. Minimalism seems very pythonic to me. ;-) Just my 2 cents. Cheers, Terry On Wednesday 04 June 2003 09:21 am, [EMAIL PROTECTED] wrote: > If I remember correctly, though, there was still a lot in question about > legitimate use cases. The web-services cluster-safety use-case I sketched > out here (http://mail.zope.org/pipermail/zope3-dev/2002-October/003112.html) > is still (perhaps) a valid case, but ONLY in a very-carefully constructed > application (and even that case leaves me wanting a better app-level way to > do it). > > I think I agree with the feeling that versions should stay in ZODB, but be > depreciated/marked as "official evil" in ZMI. > > Sean > > > -----Original Message----- > > From: Guido van Rossum [mailto:[EMAIL PROTECTED] > > > > > To anyone not following the "Problem committing zope > > 'version' objects" > > > thread on [EMAIL PROTECTED]: It's been proposed that Versions should be > > > at least stamped in the ZMI with big warnings, or possibly disabled > > > altogether. Numerous users have been bit by the fact that versions > > > basically do not work as advertised, leading in various > > cases to zodb > > > corruption or work that can't be saved. There are other > > security issues > > > that Oliver Bleutgen raised privately which I won't state here. > > > > > > Comments? Could we get at least some warnings in the ZMI before > > > 2.6.2 final? > > > > IMO versions do nothing except complexify the code. I believe it's an > > official Zope Corp position to discourage them for new projects. Yet > > Jeremy Hylton seems to think that they are somehow useful and has > > carefully preserved them in ZODB 4 (== Zope 3). If it were up to me, > > they would have been gone, with a big helping of YAGNI! > > > > --Guido van Rossum (home page: http://www.python.org/~guido/) -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
