[Zope-dev] implementing zope.component 4.0

[Chris Withers]

Martijn Faassen wrote:
> Simple adaptation:
> 
>    IFoo(adapted)

Is there an implied default of None here or would a ComponentLookupError 
be raised?

> Named adaptation:
> 
>    IFoo(adapted, name="foo")
> 
> Adaptation with a default
> 
>    IFoo(adapted, default=bar)
> 
> Multi-adaptation:
> 
>    IFoo(one, two)
> 
> Named multi adaptation:
> 
>    IFoo(one, two, name="foo")
> 
> Multi-adaptation with a default:
> 
>    IFoo(one, two, default=bar)
> 
> Utility lookup:
> 
>    IFoo()
> 
> Named utility lookup:
> 
>    IFoo(name="foo")
> 
> Utility lookup with a default:
> 
>    IFoo(default=bar)
 >
> Where "name" and "default" can be combined. The name and default keyword 
> parameters have to be used explicitly - *args is interpreted as what to 
> adapt only. Any other keyword parameters should be rejected.

*like* all of the above +sys.maxint :-)

> We could introduce the following upgrade pattern:
> 
> zope.component 3.8.0: old semantics
> 
> zope.component 3.9: old semantics is the default. new semantics 
> supported too somehow but explicitly triggered.
> 
> zope.component 4.0: new semantics is the default. Old semantics is not
> supported anymore.

I'd propose just having:

3.x -> old semantics
4.x -> new semantics

> We could, if needed, maintain zope.component 3.x in parallel with the 
> new-semantics 4.0 line for a while.

3.x should just drop into "bugfix only" mode, which it already is, and 
can be maintained as long as people are interested in maintaining it.

> A per-module triggering of the new semantics might be done like this:
> 
> from zope.component.__future__ import __new_lookup__
> 
> Is that implementable at all however? Someone needs to experiment.

If it is, that would be great, otherwise I'd prefer it just to be clear 
and simple as I suggested. I wish there was a setuptools-ish way to say 
"if a package doesn't explicitly require zope.component >= 4.0, then 
barf if we're installed". I'll enquire on distutils-sig...

> Alternatively we could do something special when we see this: IFoo(foo, 
> bar). This is ambiguous 

Is this the only ambiguous case?

>- is the new semantics in use or the old one? If 
> the adapter cannot be looked up using multi adaptation we *could* fall 
> back on single adaptation under the assumption that the old semantics 
> are desired. But this will lead to a problem if the new semantics *was* 
> desired but the component simply could not be found.

Yeah, DWIM is mad and bad, please lets not do that...

> I think it's important not to do a "big bang" upgrade but instead allow 
> people to upgrade bit by bit. It should be possible to compose an 
> application that mixes code that expects the old semantics with code 
> that expects the new semantics. A bit by bit upgrade I think would 
> ideally be on a per-module basis. I think it's important to make sure we 
> can support such an upgrade *before* we release any of this.

This paragraph is a big ask, too big in my opinion...

Chris

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk