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 )

Reply via email to