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

[Chris McDonough]

Hi yuppie...

On Jun 14, 2006, at 1:00 PM, yuppie wrote:

> Hi Chris!
>
>
> Chris McDonough wrote:
>> On Wed, 2006-06-14 at 15:42 +0200, yuppie wrote:
>>>  Reading the sources I had the impression that the fact there was  
>>> no warning for the deprecated feature was a bug and I did  
>>> consider my change a bugfix. Without warning it was already  
>>> deprecated for many years.
>> That is the case for meta_types and __ac_permissions__ but I think  
>> you
>> mistook the fact that "methods" followed a comment that said "handle
>> old-style product data" for the fact that it was deprecated.  But it
>> never was officially deprecated, nor did it ever need to be.  It just
>> *happened* to follow that comment, lumped in with meta_types and
>> __ac_permissions__.  The deprecation warning is nonsensical there.
>> "please use registerClass instead" is a non-sequitur as a deprecation
>> warning, because registerClass will not help you do what "methods"  
>> does.
>
> 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?

> I might be wrong, but it looks like the 'legacy' argument was added  
> exactly for that one purpose: Providing a migration path for  
> 'methods'. I doubt it was ever good practice to use 'methods' for  
> something else than factory methods. Don't know how many products  
> out there use 'methods' for something else. But so far the only  
> product mentioned is ExternalEditor.

PsycoPG-DA does, MySQLDA does, one of my products named  
ZopeMailArchive does.  Even in the core ZClasses/__init__.py still  
uses it.  And these are only the products I have on my hard disk.  No  
idea how many others use it.

> BTW: The name and comments in the code of the 'legacy' argument  
> make clear that using these legacy methods is deprecated as well.
>
>>> I'm fine with extending the deprecation period by one more  
>>> release cycle.
>> That's fine for __ac_permissions__ and meta_types, but can't we just
>> leave 'methods' in?  IMO, deprecating it was a simple mistake, and
>> that's OK.  We don't need to make another mistake by actually  
>> removing
>> it for the sake of being consistent with the earlier mistake.
>
> If adding deprecation warnings for 'methods' was a mistake it was  
> not a simple mistake. I still believe it should be removed.

I believe the Hippocratic Oath should be followed in subjective cases  
like this.  "First, do no harm."  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?

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

- C