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

[Philipp von Weitershausen]

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.

Then you wouldn't want to deprecate the old directives, I guess. In
general, that's fine with me, but in the end we'll also have to continue
to maintain the crappy code. I wouldn't want to do that forever.

>  - Introducing new deprecation warnings in "third-dot" releases is
>    probably inappropriate:

When we have we done this?

>  - Deprecating an API without cleaning up *all* core uses is a *lie*;

In some of the few cases where this happened was oversight and not
intentional. When you deprecate something, none of the core should still
use it. I think that's pretty clear.

>  - 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.

I think that's a big burden for refactorings. Under such a rule, Jim
wouldn't be allowed to roll out neither his adapter registry
improvements nor his Component Architecture simplification.

We're not "refactoring mercilessly." We're thinking about problems,
writing proposals, measuring risks, providing BBB and writing tests.
We'll have to trust our tests to a certain degree. If we don't then
perhaps we need more tests. We surely could use more functional tests.

I'll be fine with creating new directives instead of changing the old
ones, if that's what the majority prefers. But then I'd very much like
to see a Death Certificate for the old directives made out for some time
in the future (doesn't have to be 2 releases, could be more).

Philipp