[Zope-dev] Re: SVN: Products.ZopeVersionControl/trunk/ Purge old zope2 Interface interfaces for Zope 2.12 compatibility.

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wichert Akkerman wrote:
> Previously Tres Seaver wrote:
>> Wichert Akkerman wrote:
>>> The fact is that right now, today, we still have code that relies on Z2
>>> interfaces. Not just in third party products - current Zope2 releases
>>> rely on Z2 interfaces in some places as well.
>> Only by oversight, not by design (the only one I know of is the
>> IStreamIterator bit in ZPublisher / ZServer).
> 
> If you look at Zope itself that may be correct. Current stable CMF and
> Plone releases certainly do use them.

Not CMF:  it only *provides* them in BBB mode, via bridges from the
canonical Z3 indexes.  That has been true since the Goldegg castle sprint.

>>> Some of that code has no
>>> Z3 alternative either. I find it very hard to believe that you want to
>>> silently break all that code.  Whatever happened to our N+2 deprecation
>>> policy.
>> What I want is to stop the "n*m" + 2 policy, where m is the number of
>> layers in the stack.  I would much prefer that everything using Zope2
>> interfaces breaks *noisily*, which is why I ripped the Interface module
>> out of the Zope2 trunk, and why the "old" names are no longer present in
>> the CMF trunk.
>>
>> Zope 2.8 shipped with Five in the core *three years ago*:  from that
>> moment, the Zope2 interfaces were complete dead ends.
> 
> I've been involved with Zope development for about three years now. I
> had never heard before this month that the old interfaces were scheduled
> for removal. We have had zope.deprecate in Zope since 2.8 as well - why
> wasn't that used? Or any other visible deprecation mechanism? Why not
> add that right now to the as yet unreleased Zope 2.11 so at least we get
> a warning out?
> 
>>> If you insist on going this path we need to start adding deprecation
>>> warnings for the Z2 Interface class *now*.
>> They are already gone.
> 
> Not in 2.9, 2.10 and 2.11, two of which still see occasional maintenance
> releases and 2.11 is not final yet. We can add a deprceation warning
> there.

I would be fine with adding a warning there (actually, I would prefer to
remove them there, but I bowed to the consensus fidelium on that front).

>>>> Plone is already going to have to do this to work with CMF trunk,
>>>> because the "bridge" code which provided BBB Z2 interfaces is now gone.
>>> I've done that work on trunk already - it took a lot of work and was
>>> quite painful. There are probabyl still a few broken things that try to
>>> use Z2 interfaces.
>> Code which claims to be "working" with Z2 interfaces is already
>> crippled:  worse, it infects *other* code with that breakage.  Such code
>> *never* worked properly (those interfaces were never supported by the
>> component architecture), and was always a decoy or a booby trap.
> 
> Confusing - sure. But working.

Nope:  the fact that the things are called "interfaces" is a complete
timebomb, and one which already causes lost hair to developers whose
expectations are violated.  For instance, the "folder contents" view in
Plone *doesn't work" for objects which have Z3 interfaces.

Because they don't work with the component architecture, the Z2
interfaces are demonstrably worse than simpler schemes such as the
'portal_type' label:  they add complexity and performance overheads
without adding any value.

>> Third party code has to make adjustments sometimes, and three years is
>> long enough.
> 
> It would have been fine if there was a visible deprecation. As I said I
> for one was not aware that this was going to happen this fast (or at
> all). I find it hard to believe I am the only one.

The Goldegg project was responsible for creation of the "Framework Team"
in Plone.  at least some of the original members of the team were
actively involved in the project, and understood those goals at the time.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFINevl+gerLs4ltQ4RAqPhAJ9wErEvQDS86oLoh7Tn+dlB4Uw6agCdE1sq
1VpwGlmrOKmkuLFsX/rlyJI=
=RKro
-----END PGP SIGNATURE-----