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.



Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to