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
signature.asc
Description: Digital signature
_______________________________________________ Zope-Dev maillist - Zope-Dev@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 )
