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

[Tres Seaver]

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

Roger Ineichen wrote:
> Hi Tres
> 
>> Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? 
>> [Re:zope.browser?]
> 
> [...]
> 
>> If we that there is a real goal other than "future 
>> cleanliness" for the deprecation system, then a system which 
>> requries warnings to be explicitly enabled (e.g., via a tool, 
>> or an environment variable, or
>> something) would help reduce the burden on the downstream developer.
> 
> I think it's more then "future cleanliness". My goal is to reuse 
> as much as we can. This means, if we deprecate 
> "zope.app.form.browser.interface.ITerms". And other developer 
> will follow this refactoring and implement some nice components
> which provide some ITerms goodies. We can use this new addon
> packages in zope.app.form free projects.
> 
> If they ignore our cleanup and will still import the ITerms
> from zope.app.form.browser.interfaces. We can't use this
> packages without the get the dependency back. And that hurts.
> 
> I think such cleanup ar not optional and only a nice thing.
> Such cleanup allow us to participate on the same base.
> 
> And since BBB support is given (with a minimal deprecation
> warning sideeffect) I think this is the best what we can do.

You lose the reusability of any existing packages which supply the "old"
interface / location once you finally remove the interface from the
deprecated location.  Unless their maintainers issue new versions of
their packages (as Fred did in my example, to keep from sleeping outside
with Dino in ;), your code will not be able to use both the new version
of the framework *and* the old plugin at the same time.

"Refactor mercilessly" is a mantra of a methodology which is
specifically focused on building applications, rather tha libraries /
frameworks.  Once you have "downstream" users who are not actively
involved in the development of your package, the costs of refactoring go up.

As an example from outside Zope land:  Linux developers fiercely defend
their practice that there is no stable "ABI" in the kernel;  out-of-tree
modules have to be recompiled to be compatible with new kernel versions,
including refactorings, etc.  However, they are equally fierce in the
policy that a user-space API, once released, is maintained *forever*.
User-space code which uses such an API *must* continue to work.


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

iD8DBQFJTYlG+gerLs4ltQ4RAqd7AKCpf4om3G6gpx0ilfiw1/83JgoxUgCgjBBP
GBHZ4dF3Ts2UmVWKEZD5+IE=
=RCah
-----END PGP SIGNATURE-----