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
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
