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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )