[Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]

[Christian Zagrodnick]

On 2008-12-15 13:44:43 +0100, "Roger Ineichen" <dev at projekt01.ch> said:

> Hi Christian
> 
>> Betreff: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:
>> zope.browser?]
> 
> [...]
> 
>>>> A deprecation warning isn't bad. But I think we should not
>> deprecate
>>>> the use of ITerms from zope.app.form. I don't see a gain
>> in this API
>>>> change.
>>> Imo it's a bad idea to keep exactly the same interface in 2
>> places. At
>>> least i don't see an improvement or convenience in keeping it.
>>> 
>>> the only real reason to keep it is for legacy reasons, but import
>>> adoption should not be that hard ;)
>> 
>> No it is not. I just question why we force everybody to use
>> the new location when we did not do so with ISite. It is
>> exactly the same issue with two different outcomes.
>> 
>> The canonical location for ISite is zope.location now. It
>> used to reside in zope.app.component but was moved to
>> zope.location w/o deprecating the use from zope.app.location
>> to keep the API backward compatible. I really do not see a
>> differrence to ITerms here.
> 
> This doesn't have to do with bachward compatibility. Deprecated
> imports are backward compatible too. I think someone just missed
> to deprecate that interface.

Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html

> 
> 
> The reason why we should deprecate interfaces is: If a package
> still points to the old interface location, this package whould
> bring in the old dependency we tried to remove.

Depends. See below.

> 
> I guess, since you are asking for support the old location,
> this doesn't hurt you because you are using both packages.
> Others don't. Any other packages which doesn't adjust the
> import to the new location will hurt others which do not use
> both packages.

If there is a packe which uses ITerms but  not zope.app.form this must 
be updated then. For packages which use zope.app.form this is not so 
important. I think they will be updated sooner or later when code is 
touched anyway because the new import is much shorter. But the 
deprecation *forces* everybody to update now. And this interface is 
used in *many* places.

> 
> I see that this makes it more a good thing for others then
> for yourself. But I think that's fine. Isn't it?



> 
> In my point of view, deprecation messages are a great concept
> to announce changes/improvments without to break compatibility.
> Without such announcements our code can get very quick out
> of date and we have no change to know about that.

Yes, for necessary API changes which do not need to be shipped 
immeadiately I can see that.


> 
> btw,
> we also should deprecate the ISite interface at the old location.

Same question: what would you gain here? Packages are slowly migrated 
to using the new ISite import but nobody is forced to change all the 
code right now to get rid of all the deprecation warnings.



-- 
Christian Zagrodnick · cz at gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development