Wichert Akkerman wrote:
- getToolByName gives us a lot of deprecation warnings. We can do two
things: undeprecate getToolByName in plone 3.0, deprecate in 3.5 and
remove in 4.0. Or fix all getToolByNames in 3.0. This is doable with
some effort.
>
The last one is a decision that we need to make.
I would be really careful to toe the policy line on deprecations here if
only to toe the line. getToolByName() is *incredibly* pervasive in third
party product code, and breaking things just because we want to get rid
of that method is silly. This is similar to the zLOG deprecation and
un-deprecation. The benefits of total deprecation do not outweigh the
cost. Even if fixing it in most cases is not that hard, it's time consuming.
I would like the following:
- Leave it now. Have it emit warnings, but preferably not duplicate
warnings (i.e. for the same tool, or, better yet, for the same calling
code, but that may be hard). With too many warnings, people get giant
log files and more important log messages drown.
- If at any point supporting the old API becomes too difficult, remove
it. I don't see that happening very soon, though.
- Consider some kind of compitability alias mechanism, so that when
people keep using getToolByName(context, 'portal_types') we translate
that to getUtility(ITypesTool), for as long as we need to (but still
warning).
Removing in 3.5 sounds completely unrealistic to me. If we find that by
4.0 most third party products that count (i.e. would be otherwise
compatible) have been fixed, we can consider removal.
It will take a couple of days for this to settle down, I'm leaving for a
week of snowboarding tomorrow evening, so here is my proposal: we delay
the beta a bit further to Monday, March 19. At that point I'll make a
decision on deprecating or undeprecating getToolByName and make a
release based on whatever product and package releases exist at that
time.
It's a shame we have to postpone the beta further, but the CMF changes
require some important change in our codebase that need to be finished.
But better the hit now than later. :)
Note - I can't produce any new packages by March 19th (still on holiday
then, back on the 21st), but my packages ought to be stable for now.
Martin
_______________________________________________
Framework-Team mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/framework-team
