[Zope-dev] Re: Time-based releases a good idea?

[Chris McDonough]

On Jun 14, 2006, at 5:30 PM, yuppie wrote:

> Hi Chris!
>
>
> Chris McDonough wrote:
>> On Jun 14, 2006, at 1:00 PM, yuppie wrote:
>>> It's not that simple. registerClass has an optional 'legacy'  
>>> argument that does something quite similar. It just monkey  
>>> patches ObjectManager instead of Folder. So at least for some use  
>>> cases registerClass *will* help you.
>> That would be helpful if I had a class to register.  If I don't,  
>> it's an even worse hack than "methods" is.  This is the case for  
>> External Editor.  It has no addable types.  And switching over to  
>> use something named "legacy" seems silly.  How long until that's  
>> deprecated under the new clean-up-the-cruft-or-die regime?
>
> AFAICS the Right Way to modernize ZopeMailArchive and  
> ExternalEditor would be using adapters. I don't recommend to abuse  
> registerClass instead of 'methods'. And using a monkey patch is  
> only the more obvious way of doing the wrong thing.

OK.  I still think this is wrong, but I don't have the time to argue  
anymore.

>> I believe the Hippocratic Oath should be followed in subjective  
>> cases like this.  "First, do no harm."
>
> Cruft does harm. It discourages people who want to understand and  
> improve Zope. And it encourages people to stick to bad coding habits.

Nope.  Sorry.  It's the stinky glue that keeps everything running.  I  
have a sense that you don't appreciate the full negative impact of  
these kinds of changes because you haven't really thought about the  
impact to the third-party dependency graph very much.

>
>> If we do deprecate it, we will need to have the deprecation  
>> warning *at least* say something better than "use registerClass",  
>> because that's meaningless.  Maybe it should give a URL that has  
>> content that explains how to monkey patch OFS.Folder.  But in that  
>> case, it just seems dumb to deprecate; we know "methods" works.   
>> Maybe we can provide a utility method that does the same thing as  
>> 'methods' does?
>
> Why do you want to have special support for monkey patching Folder?  
> Which use cases justify to pollute the Folder API in that way?

We can't rely on browser view lookup here.  I'm  will not break third- 
party code that relies on being able to look up EE's  
"externalEditLink_" by asking for it against any folder via getattr.   
At least not when there's google hits for that string that point into  
silva, Zelenium, Axiom, Plone, CPS, and zpydoc.  That would be dumb,  
because some of these products might not have even been updated to  
run against Zope 2.8+, and thus which would not be able to use Five  
even if they wanted to.

So Florent has already changed EE on the trunk to do its own monkey- 
patch of Folder, which will stay.  EE will start to break in 2.11 if  
I (or someone else) haven't gotten the time by then to make a new  
release of EE with that code.  So be it.

>
>>> You ignored my argument regarding the shorter deprecation period.  
>>> But if there is a consensus that old deprecations without  
>>> explicit deprecation message don't count I'm fine with extending  
>>> the period for __ac_permissions__ and meta_types as well.
>> I did not mean to ignore it, I thought I had acknowledged it in  
>> another mail, sorry.
>
> No problem. And meanwhile you answered this in another mail. While  
> I still believe there was a good reason to differentiate between  
> new and historical deprecations I now see that it is hard to  
> communicate the difference and all the confusion it caused is not  
> worth the shorter warning period.
>
> So I'm fine with starting new deprecation periods for all code that  
> was deprecated the old way (not using warnings). Of course new  
> deprecation periods have to start in a .0 release.

OK.

- C