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

[Roger Ineichen]

Hi Christian

> Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? 
> [Re:zope.browser?]
> 
> 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. 

All I can say about that is: If there is an improvment in the API
we need to announce that. Otherwise other developer will not follow
or follow at a time they think it's better for them. Or even 
worse, they don't know about that.

Deprecation messages will kick them a little bit and they get forced
to update their code in a acceptable way ;-)

The question now is, should we be lazy and skip this information
and support nice deprecation free test output or support developer
with information about the newest API changes in form of deprecation
message hints?

Regards
Roger Ineichen