[Zope3-dev] Re: RFC: The browser:page compromise

[Tres Seaver]

-----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          tseaver at palladion.com
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          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com