[Zope-dev] implementing zope.component 4.0

[Martin Aspeli]

Martijn Faassen wrote:
> 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

Yeah. I'm kind of astonished at how many people are happy to accept 
that, though.

> [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.

Sorry, I just don't buy it. The *moment* someone requires >= 4.0, you're 
screwed.

And per-module flags are ugly and confusing. I'm quite sure most people 
never import from __future__ in Python, just because it's so hard to see 
what's going on and so annoying to have to remember to do it.

> 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.

This sounds like we're making excuses for making a bad choice. What's 
the point of releasing a package if we encourage people not to use it? 
Or not to use it "yet"? When does "yet" end?

We won't be able to control what people do in their code. And it only 
takes one package to depend on 4.0 for it to all go wrong for anyone 
using the current, documented, *encouraged* pattern.

> The documentation issue is a more severe one.

And not one that we can brush aside. It's criminal. I'm going to have to 
go and update a ton of documentation and say, "you need to figure out 
which version you're on; if you're on version < 4, this bit of code does 
this; if you're on version 4.0 or later, it does something entirely 
different". To do that *intentionally* is just wrong. Most people don't 
even know how to figure out which version they're using. For most 
people, it involves opening binaries in the bin/ director of their 
buildout and check out the sys.path mangling.

> [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. :)

Count yourself lucky. ;)

>> 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.

I think the answer should be "never". :)

To put this into perspective: we're going to cause a lot of pain for a 
lot of people for something that is *purely* cosmetic. We're indulging 
in a whim for "perfect" API design at the expense of people who signed 
up to our old API.

Sometimes, we need to accept that our past decisions are with us to 
stay. I think that's a sign of maturity and attention to our customers, 
rather than weakness.

There are solutions in these threads which are backwards compatible, or 
at least backwards compatible in the vast majority of cases. They may 
not be exactly as pretty, but in my book they are infinitely preferable.

I would much, much rather have none of these improvements and not break 
all that code. What we have now works. We would just like it to be a 
little bit prettier and a bit more obvious. Those are laudable goals, 
but not at any expense.

And yeah, I feel pretty strongly about this. ;-)

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book