[Zope-CMF] Re: [dev] tools-as-utilities roadmap

[yuppie]

Hi!


Wichert Akkerman wrote:
> Previously Tres Seaver wrote:
>> yuppie wrote:
>>> Tres Seaver wrote:
>>>> yuppie wrote:
>>>>> Or do you prefer to keep things as they are over a less clean switch to 
>>>>> utilities?
>>>> Yes.  I'd rather get 2.1 out, even with tools-which-can't-be-utilitiies
>>>> as they are, then delay.
>>> I'm not just talking about CMF 2.1. I'm fine if the result of this 
>>> discussion is a roadmap that starts with CMF 2.2. But if there is no 
>>> realistic roadmap at all we might better revert all the 
>>> tools-as-utilities changes. The few utilities we have right now are not 
>>> worth the trouble. Starting the migration makes only sense if we have a 
>>> plan to finish it.
>>>
>>>> Note that this problem is basically due to the desire to cache the
>>>> aq_chain for utilities:  if we punt on that, we can then defer this
>>>> whole issue.
>>> Maybe that's your reason why you didn't argue against the proposal. I 
>>> consider the possibility to cache utilities just a side effect of 
>>> removing the REQUEST from the wrappers.
>> I thought that caching was the *reason* for removing the request;
>> otherwise, we could just re-wrap the tool in each 'getUtility' call and
>> it would have access to the request as it does today.
>>
>>> This is not about making the implementation easier. This is about 
>>> defining what utilities are. If they provide self.REQUEST they become a 
>>> utility-view monster that has not much in common with Zope 3 utilities. 
>>> Reducing Zope 2 magic to a minimum if we use Zope 3 technology is a good 
>>> thing - even if that forces us to be more explicit about required 
>>> REQUEST arguments.
>> That's fine, but just means that we have to invent *new* utilities and
>> change application code to begin calling the new APIs:  right now,
>> nobody in the wild expects to pass a REQUEST to most of those methods.
>>
>> Once the replacement utilities are available, we can start deprecating
>> the "tool-ish" APIs.  Note that such a change is *way* too late in the
>> release cycle for 2.1.
> 
> Aren't we talking about a post-2.1 roadmap now?

Well. The 2.1 changes are based one the assumption that we switch 
quickly and completely to utilities, making all tools work as utilities. 
The roadmap proposed by Tres means it will take several years and we'll 
have to work with tools and utilities side by side for a long time.


I can live with that approach, but would like to see CMF 2.1 adjusted:

'getToolByInterfaceName' is a completely misleading method name if tools 
will not become utilities. This method has no 'context' (or 'REQUEST') 
argument, so it can't return tools. It returns utilities. 
'getUtilityByInterfaceName' would be a much better name for a 
'getUtility' replacement used in untrusted code.

I propose to run a search 'n' replace *before* the next beta.


Cheers,

	Yuppie