Hi Jens,
A warning is a warning is a warning, there's no lower level, and people won't see anything if it isn't in their faces. The usage of something like a debug error message is unprecedented, counterintuitive and will not compel anyone to fix their product. We finally have a _workable_ deprecation policy with accepted ways to signal deprecation and accepted deprecation periods, I'm against creating special precedents for no other reason other than to give anyone, be it Plone users or third party coders or anyone else, a _false_ sense of security.
We do have precedent in Zope 3 as well as Plone where deprecation periods were extended because the breakage was unrealistic.
A warning is of course one thing. If getToolByName() is gone entirely in a year (I don't know if that was your intention or not) it's pretty scary. Surely, some things deserve longer deprecation periods than others, and getToolByName() is used in pretty much every third party product (certainly every one I've written).
The task isn't rocket science, it's just dull work. I know that because I've spent a long time doing it on that branch. Besides, a deprecation warning will only show up once for every specific call if I remember correctly.
That's good - I was going to suggest something like that. :)
Keep in mind that the only tools which will cause the DeprecationWarning to show are those defined in the CMF package. No third-party "portal_foobar" tool would cause it.
Right.
If you consider the relatively glacial speed of CMF releases you'll see there's nothing "quick" when the normal policy of removal two releases down the line is applied. The earliest time getToolByName could possible go away would be 2.3, and I strongly doubt it will happen then. We will warn people that it *might* happen, though.
Cool.
I do appreciate your desire to be conservative, but it's a bit hard to understand when I hear so many voices from the upper echelon of Plone developers wanting to completely revamp (for very good reasons) large parts of it.
I completely agree that this is the right direction and I will certainly want to use this in my own code and promote it as widely as possible.
I guess I'm a bit wary by some of the experience from Zope 3 (or Zope 2) where for a time the desire to "tidy" got a bit strong and things were removed because the policy said so, but which caused a lot of breakage that wasn't really necessary.
So long as tools remain and remain in content space, getToolByName() can continue to exist and work (and warn, I guess); it's only a couple of lines of code, even. The deprecation serves a purpose in terms of allowing better local overrides and allowing us to eventually move the tools out of content space. It also helps avoid a dependency on CMFCore where products were only importing getToolByName() to use tools.
I would argue that removing it wouldn't be better than keeping it in (with a warning), practically speaking, until tools are removed from content space, say.
Once again, I think we agree on direction, perhaps disagreeing on speed. Martin _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
