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

[Marius Gedminas]

On Tue, Dec 16, 2008 at 03:45:01PM -0500, Tres Seaver wrote:
> Martijn Faassen wrote:
> > Christian Zagrodnick wrote:
> > [snip]
> >> Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html
> > 
> > Weird. At first glance I do not understand the context of that decision. 
> >   There was a decision to "avoid deprecation" made by it doesn't seem to 
> > be motivated in the discussion:
> > 
> > "- zope.app.component.interfaces then can import ISite from the new
> > place to avoid deprectation."
> > 
> > You're saying, I think, that we should do the same thing as in that 
> > discussion to avoid deprecation too. But I cannot find a reason to avoid 
> >   deprecation in the original discussion. Could you elaborate on your 
> > thinking?
> > 
> > I'm hoping to soon go through quite a few packages and deprecate lots of 
> > stuff by moving it into other packages to try to tidy up the dependency 
> > structure. If there are important arguments against deprecation warnings 
> > I'd like to understand the background.
> 
> One issue is that adding deprecation messages for importing symbols from
> the old makes all "downstream" code add ugly BBB warts in order to
> suppress them when run against multiple versions.

Also consider deprecation messages triggered not by code, but by the use
in existing ZODB databases.  ISite is often directlyProvided by
persistent objects, which makes the ZODB store a fully-qualified
interface name.  You'd need an evolution script to walk the container
tree and force a repickling of every site to prevent the app from
spewing deprecation warnings at runtime.

Regards,
-- 
http://pov.lt/ -- Zope 3 consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20081217/da63cf5f/attachment.bin