Hash: SHA1

Roger Ineichen wrote:
> Hi Tres
>> Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? 
>> [Re:zope.browser?]
> [...]
>> 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.
> Yes, that's exactly what deprecation message do. Deprecation 
> messages in tests do not have to win a beauty award. The goal
> of a deprecation message is to inform developers about upcomming
> changes. This ugly BBB output is very important to me!
> This allows us to schedule our work and we don't run into
> removed backward compatibility issues. This makes deprecation
> messages something like a reminder and nothing which we should
> ignore.
> If we don't use deprecation messages we can not do future cleanup
> because we can't remove old not deprecated code.
> This means using deprecation message or not depends on the need 
> for a future cleanup. If we like to support an old interface
> location then we don't need deprecation messages. But if we
> like to remove the interface at the old location in the future
> then we need to deprecate them. This has nothing to do with
> beautify our test output.

I think you missed my point:  third-party developers who want their code
*not* to emit the deprecation warnings when used across both old and new
versions of "our" library have to add nasty BBB cruft to *their* code:
we've shifted the BBB burden to them, often for a small marginal benefit
to ourselves.

- --
Tres Seaver          +1 540-429-0999          tsea...@palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to