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

[yuppie]

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.

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

The obsolete ZPsycopgDA 1.1 just uses it for factory methods, ZPsycopgDA 
2.0 doesn't use it.

The last ZMySQLDA release is 5 years old. It also uses it for factory 
methods.

These 2 examples show that some very old products still use 'methods' 
instead of registerClass. They can easily be updated.

ZClasses is no product and unless some other magic uses 'methods' it is 
ignored anyways.

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

Cruft does harm. It discourages people who want to understand and 
improve Zope. And it encourages people to stick to bad coding habits.

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

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


Cheers,

	Yuppie