[Zope-dev] SVN: zope.app.component/trunk/ Please, don't just remove things that could be used in users code.

[Tres Seaver]

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

Dan Korostelev wrote:
> 2009/2/6 Martijn Faassen <faassen at startifact.com>:
>>> Yep. Also, as I said before I think we also need to use deprecation
>>> warnings for imports that are not classes for persistent objects
>>> (until Chiristian writes the tool to upgrade them :)).
>> As far as I understand in a recent discussion people indicated they
>> didn't like deprecation warnings anywhere, as they are forced on third
>> party users of code that itself isn't deprecating anything. Since
>> Christian's tool is as I take it well underway couldn't we just rely
>> on this? Also since it actually *fixes* the state of a ZODB, instead
>> of just giving a lot of warnings and then leaving the helpless
>> developer with writing some scary custom upgrade code.
> 
> I don't think there was a consensus about that.
> 
> For ZODB objects I think its okay for now not to use deprecations and
> to use the upgrade tool, but for the imports of other things that were
> moved elsewhere, I still think we need to bug developers that they
> need to upgrade their code with deprecation warnings, so we can
> eventually remove old imports. Oh, and BTW, if we use the "zodb fix
> tool", it's also okay to raise deprecation warnings about ZODB
> objects, as it's really easy to fix with the magic tool and again, we
> can eventually remove the deprecated import and make our code more
> clean.
> 
> Let's discuss it once again :)

OK.  I have argued that leaving BBB imports in place forever, without
deprecation, is the best choice, because it leaves working code working,
and takes *less* maintenance than the "deprecate, then remove" dance we
have been doing.  Deprecation warnings which get emitted in huge swaths
every time the appserver starts de-sensitize folks to them pretty
quickly, making the warnings worse than useless.

Martijn hoped for a tool which would help developers find places in
their code which used the BBB locations, in order to help them
modernize.  I would be fine with leaving artifacts in the code to help
such a tool (e.g., some variation on the zope.deferredimport dance).


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

iD8DBQFJjGmQ+gerLs4ltQ4RAsYtAKCHJJsC/jCyw/cB5dHSdG678CdfKQCfXDFD
UtrRsrV0gpPF3eSJm2HkdAk=
=6E/I
-----END PGP SIGNATURE-----