Mailing List Archive: Zope: Dev

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

Index | Next | Previous | View Threaded

tseaver at palladion

May 22, 2008, 7:10 AM

Post #1 of 11 (568 views)
Permalink

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

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

Wichert Akkerman wrote:
> Previously Laurence Rowe wrote:
>> Log message for revision 86849:
>> Purge old zope2 Interface interfaces for Zope 2.12 compatibility.
>
> This change, and other, do something very dangerous: they replace the
> Zope2 interface with a Zope2 interface under the exact same name and
> location. This is bad: it wrongly makes people thing their code keeps
> working while they are now suddenly doing things like putting Z3
> interfaces in __implements__ tuples and silently changes calling
> conventions.
>
> If you make such changes please make sure to either change the interface
> name or only have it importable from another location.

- -1. Anybody who still has '__implements__' in their code needs to rip
it out immediately, replacing it with the equivalent Z3 idioms. Lots of
code has *both* idoms, which is just silly in this day and age: the Z2
interfaces have been worthless for three years now (since Five landed in
the Z2 core in April 2005.

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 note with some frustration that ripping the Z2 interfaces out of Plone
code was slated to be done during the goldegg project, which closed two
years ago, with most of the work done in fall 2005.

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

iD8DBQFINX7F+gerLs4ltQ4RAhRYAJ4nKgW45zjL7Sta0DwhD4HPLi3yrgCfaXnA
gIynXQMjqwbyAXOwuiml+Bc=
=x/Sa
-----END PGP SIGNATURE-----

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

wichert at wiggy

May 22, 2008, 7:31 AM

Post #2 of 11 (549 views)
Permalink

Re: Re: SVN: Products.ZopeVersionControl/trunk/ Purge old zope2 Interface interfaces for Zope 2.12 compatibility. [In reply to]

Previously Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Wichert Akkerman wrote:
> > Previously Laurence Rowe wrote:
> >> Log message for revision 86849:
> >> Purge old zope2 Interface interfaces for Zope 2.12 compatibility.
> >
> > This change, and other, do something very dangerous: they replace the
> > Zope2 interface with a Zope2 interface under the exact same name and
> > location. This is bad: it wrongly makes people thing their code keeps
> > working while they are now suddenly doing things like putting Z3
> > interfaces in __implements__ tuples and silently changes calling
> > conventions.
> >
> > If you make such changes please make sure to either change the interface
> > name or only have it importable from another location.
>
> - -1. Anybody who still has '__implements__' in their code needs to rip
> it out immediately, replacing it with the equivalent Z3 idioms. Lots of
> code has *both* idoms, which is just silly in this day and age: the Z2
> interfaces have been worthless for three years now (since Five landed in
> the Z2 core in April 2005.

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

If you insist on going this path we need to start adding deprecation
warnings for the Z2 Interface class *now*.

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

Wichert.

--
Wichert Akkerman <wichert[at]wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

tseaver at palladion

May 22, 2008, 7:32 AM

Post #3 of 11 (550 views)
Permalink

Re: SVN: Products.ZopeVersionControl/trunk/ Purge old zope2 Interface interfaces for Zope 2.12 compatibility. [In reply to]

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

Laurence Rowe wrote:

> It is still needed in Zope 2.11 for
> ZPublisher.Iterators.IStreamIterator. This is only used in a handful
> of places though.
>
>> 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 just ripped out the old Z2 interfaces from Plone trunk, but there
> is still work to be done on tidying this up and working out the
> migration path for Archetypes code (things such as
> Products.validation).

Great!

>> I note with some frustration that ripping the Z2 interfaces out of Plone
>> code was slated to be done during the goldegg project, which closed two
>> years ago, with most of the work done in fall 2005.
>
> Well, we're where we are rather than where we'd like to be ;-)

I'll note that providing "bend over backward" BBB code is part of the
reason that we got here.

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

iD8DBQFINYQQ+gerLs4ltQ4RAjocAKCxoYVEOwxnPJij6MxyGN4AGH4z+ACfayJC
de84CNz3c3nQwLrYTwH8HJ8=
=q5/q
-----END PGP SIGNATURE-----
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

tseaver at palladion

May 22, 2008, 7:45 AM

Post #4 of 11 (547 views)
Permalink

Re: Re: SVN: Products.ZopeVersionControl/trunk/ Purge old zope2 Interface interfaces for Zope 2.12 compatibility. [In reply to]

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

Wichert Akkerman wrote:
> Previously Tres Seaver wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Wichert Akkerman wrote:
>>> Previously Laurence Rowe wrote:
>>>> Log message for revision 86849:
>>>> Purge old zope2 Interface interfaces for Zope 2.12 compatibility.
>>> This change, and other, do something very dangerous: they replace the
>>> Zope2 interface with a Zope2 interface under the exact same name and
>>> location. This is bad: it wrongly makes people thing their code keeps
>>> working while they are now suddenly doing things like putting Z3
>>> interfaces in __implements__ tuples and silently changes calling
>>> conventions.
>>>
>>> If you make such changes please make sure to either change the interface
>>> name or only have it importable from another location.
>> - -1. Anybody who still has '__implements__' in their code needs to rip
>> it out immediately, replacing it with the equivalent Z3 idioms. Lots of
>> code has *both* idoms, which is just silly in this day and age: the Z2
>> interfaces have been worthless for three years now (since Five landed in
>> the Z2 core in April 2005.
>
> 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).

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

> If you insist on going this path we need to start adding deprecation
> warnings for the Z2 Interface class *now*.

They are already gone.

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

Third party code has to make adjustments sometimes, and three years is
long enough.

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

iD8DBQFINYb1+gerLs4ltQ4RAiyTAJoDdaV4jPZ+Br6Rd+OahLuPHgbqXACg0C7V
Bt1gex4+fFwt2A7BOpVo9Kw=
=hQci
-----END PGP SIGNATURE-----
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

wichert at wiggy

May 22, 2008, 11:23 AM

Post #5 of 11 (553 views)
Permalink

Re: Re: SVN: Products.ZopeVersionControl/trunk/ Purge old zope2 Interface interfaces for Zope 2.12 compatibility. [In reply to]

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.

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

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

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

Wichert.

--
Wichert Akkerman <wichert[at]wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

tseaver at palladion

May 22, 2008, 2:55 PM

Post #6 of 11 (542 views)
Permalink

Re: Re: SVN: Products.ZopeVersionControl/trunk/ Purge old zope2 Interface interfaces for Zope 2.12 compatibility. [In reply to]

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

dieter at handshake

May 23, 2008, 11:38 AM

Post #7 of 11 (513 views)
Permalink

Re: Re: SVN: Products.ZopeVersionControl/trunk/ Purge old zope2 Interface interfaces for Zope 2.12 compatibility. [In reply to]

Tres Seaver wrote at 2008-5-22 10:45 -0400:
>> ...
>> 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).

"Products.PlugcinIndexes.common.UnIndex.UnIndex" still uses
both "__implements__" and "implements".

True, the Zope2 interfaces are defined from the Zope3 ones
via a magical "Interface.bridge.createZope3Bridge".

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

Formerly, both you and me, have been strong advocates for
backward compatibility. What happened that you now want to
break things drastically?

>Zope 2.8 shipped with Five in the core *three years ago*: from that
>moment, the Zope2 interfaces were complete dead ends.

Precisely this Five version suggests to use "__implements__"
and "implements" together...

--
Dieter
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

dieter at handshake

May 23, 2008, 11:44 AM

Post #8 of 11 (513 views)
Permalink

Re: Re: SVN: Products.ZopeVersionControl/trunk/ Purge old zope2 Interface interfaces for Zope 2.12 compatibility. [In reply to]

Wichert Akkerman wrote at 2008-5-22 20:23 +0200:
> ...
>> 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.
>
>> 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.

You are not the only one. I am another one...

And I can support you: we had the policy that things do not get
rid off the core without a clear deprecation phase of at least 1
(or even 2) release cycles.

I think, Tres, too, agreed to the policy although now, he wants to
violate it....

--
Dieter
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

tseaver at palladion

May 23, 2008, 2:54 PM

Post #9 of 11 (508 views)
Permalink

Re: SVN: Products.ZopeVersionControl/trunk/ Purge old zope2 Interface interfaces for Zope 2.12 compatibility. [In reply to]

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

Dieter Maurer wrote:
> Tres Seaver wrote at 2008-5-22 10:45 -0400:
>>> ...
>>> 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).
>
> "Products.PlugcinIndexes.common.UnIndex.UnIndex" still uses
> both "__implements__" and "implements".
>
> True, the Zope2 interfaces are defined from the Zope3 ones
> via a magical "Interface.bridge.createZope3Bridge".

Exactly: they define them only for notional backward compatibility.
They don't actuallly *use* them for anything. I'm arguing that the time
is *now* to drop the BBB, which is not going to break any code which was
actually *working* in terms of the expected behavior of interfaces.
Software which hasn't been updated to use Z3 interfaces at this point
won't *ever* get updated if we leave the BBB code in place.

>>> 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.
>
> Formerly, both you and me, have been strong advocates for
> backward compatibility. What happened that you now want to
> break things drastically?

Three years later, and folks still haven't gotten with the program. I'm
tired of "carrying them on the books."

>> Zope 2.8 shipped with Five in the core *three years ago*: from that
>> moment, the Zope2 interfaces were complete dead ends.
>
> Precisely this Five version suggests to use "__implements__"
> and "implements" together...

It provides the Z2 interfaces or *backward compatibilty*: those
interfaces never worked for component dispatch (which makes them useless
for their major purpose), and the various places in the Zope2 code which
attempted to allow "sniffing" them were crufty bug magnets.

Encouraging people to take another year ripping them out is silly.

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

iD8DBQFINzz7+gerLs4ltQ4RAo5BAJ0eiO1o3rX8916xUi5IvTna657HHACguk06
Bza+2vVEYDZRRqx5sHI7eKU=
=334q
-----END PGP SIGNATURE-----

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

wichert at wiggy

May 24, 2008, 2:22 AM

Post #10 of 11 (495 views)
Permalink

Re: Re: SVN: Products.ZopeVersionControl/trunk/ Purge old zope2 Interface interfaces for Zope 2.12 compatibility. [In reply to]

Previously Tres Seaver wrote:
> They don't actuallly *use* them for anything. I'm arguing that the time
> is *now* to drop the BBB, which is not going to break any code which was
> actually *working* in terms of the expected behavior of interfaces.
> Software which hasn't been updated to use Z3 interfaces at this point
> won't *ever* get updated if we leave the BBB code in place.

Until we start seeing some *visible* deprecation warnings in code I will
keep objecting. As I said before I have managed to work with Zope for a
few years now without ever having seen a single deprecation statement
for Z2 interfaces. Right now I have a feeling that the strategy is 'oh,
this has been deprecated for years but we forgot to put the mesasge out,
but we'll remove it anyway'. That can't be right.

Add some zope.deprecate calls around Z2 interfaces in the 2.9-2.11
trees. Really.

Wichert.

--
Wichert Akkerman <wichert[at]wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

tseaver at palladion

May 24, 2008, 10:30 PM

Post #11 of 11 (485 views)
Permalink

Re: SVN: Products.ZopeVersionControl/trunk/ Purge old zope2 Interface interfaces for Zope 2.12 compatibility. [In reply to]

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

Dieter Maurer wrote:
> Tres Seaver wrote at 2008-5-23 17:54 -0400:
>> ...
>> It provides the Z2 interfaces or *backward compatibilty*: those
>> interfaces never worked for component dispatch (which makes them useless
>> for their major purpose), and the various places in the Zope2 code which
>> attempted to allow "sniffing" them were crufty bug magnets.
>>
>> Encouraging people to take another year ripping them out is silly.
>
> It is the agreed upon policy: step 1 we deprecate the feature
> and issue deprecation warings indicating when the feature will go
> away; step 2 we remove the feature.
>
> Why do you not have introduced the deprecation warnings years ago?
> Do it now at least for Zope 2.11 as you have already removed
> the code on the trunk.

Done:

http://svn.zope.org/Zope/branches/2.11/?rev=86939&view=rev

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

iD8DBQFIOPl8+gerLs4ltQ4RAqfLAJ9S7a/Uxhw+L9ECRy/erJ57fBlidQCgx1JX
FRI1z2B5DiMIqoiM6T299tE=
=koMz
-----END PGP SIGNATURE-----

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com