Martin Aspeli wrote:
Martijn Faassen wrote:
Multi-adaptation:
IFoo(one, two)
Please note that this will break an incredible amount of code "in the wild". A good number of my packages do something like this:
foo = IFoo(context, None) if foo is None: ...
Yes, that this would break a lot of code is well known [backwards compatibility discussion]
-1
Because we now have so many packages and things are being released as eggs and mixed up in various platforms and projects, this type of "gross" backwards incompatibility is virtually impossible to manage.
To take an example, I'm sure Stefan & co will release z3c.form 3 depending on zope.component 4 before long, and we'll want to use that in Plone. Except we can't, because even if z3c.form never uses the IFoo(one, two) syntax, everything in Plone that uses IFoo(context, None) would suddenly break.
That's why I think it's important to have a: * a zope.component 3.x that supports both patterns * a per-module way to indicate whether the new API should be used. We'd commit to maintaining zope.component 3.x in parallel with zope.component 4.0. We'd recommend to people *not* to require zope.component 4.0 for a period, or perhaps we'd even not release it for quite a period. The documentation issue is a more severe one. [snip]
I think Jim said once, "we can't ever have backwards incompatibility". Other "serious" platforms like Java or .NET have a similar stance. They deprecate liberally, but never actually break anything.
(Remember java.util.Data and java.util.Calendar?)
No, I don't remember. :)
We may never be able to do that completely, and we may *want* to root out some dodgy bits of code that few people use. But breaking something so fundamental and so commonly used would be criminal, in my book.
Taken into consideration.
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.
I'm not sure that's going to be possible. As soon as someone does zope.component >= 4.0 in their setup.py, you're screwed.
This implies we don't want to release zope.component 4.0 for a long time yet. Regards, Martijn