-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote:
> Tres Seaver wrote: > >>-1 on breaking ZCML in the wild. Propose *new* directives which have >>new semantics, but for existing directives, we should clean up the >>implementation rather than modifying semantics. E.g., we should be able >>to rip out the gunk which synthesizes new classes in 'browser:page': I >>think it derives from a period before we could assign a >>'__Security_checker__' attribute to instances, and so *had* to have a >>class in order to make the checker stuff work. > > > It's not only the security checker. It's the whole IBrowserPublisher > implementation that's jerked into the subclass. My proposal is exactly > stopping that. > > Of course, we can implement new directives (possibly with the same name > but different namespace URI) and deprecate the old ones. But that's only > marginally different from what I propose. The difference is that your proposal *forces* people to change previously-working ZCML; that is the thing to which I am opposed. I think we have been too "deprecation happy" over the last few releases; in particular: - Introducing new deprecation warnings in "third-dot" releases is probably inappropriate: people shouldn't need to think about such issues during "normal maintenance" upgrades, where we explicitly promise API stability. - Deprecating an API without cleaning up *all* core uses is a *lie*; I would be strongly in favor of reverting *any* such cases as "premature." Some of the lies we have propagated here are also violations of my first tenet, which reinforces their inappropriateness. - Deprectaion of an older, stable alternative, *no matter how grotty,* should go hand in hand with *lots* of confidence that the new favored alternative really is superior, and by enough margin to make the switch worthwhile. In my mind, this means that the new implementation needs to be rolled out *in production* and tested in the wild *before* we can deprecate the older alternative. "Refactor mercilessly" is not a mantra which works very well for frameworks, particularly once they have rolled out with third party dependencies. Note that classic XP is specifially "framework averse", and comes out of a purlely leafmost / application-centric development model. It is also hostile to remote / dispersed development, which we routinely practice. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFER92N+gerLs4ltQ4RAscJAJ9/odAd+QLQ75PLznSIgKyqctY5zwCgp79V ZsMgT6G7slYBbfFXfqWBkL0= =6RBB -----END PGP SIGNATURE----- -- =================================================================== Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
