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

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.


Framework-Team mailing list

Reply via email to