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
_______________________________________________
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 )