Re: implementing zope.component 4.0

Martijn Faassen <[email protected]>
Newsgroups gmane.comp.web.zope.devel
Message-ID <[email protected]>
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  -  [email protected]
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 )
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.