Christian Theune wrote at 2006-12-17 11:34 +0100:
>Jupp. Is there any technical chance the we can use the deprecation mechanism
>or something like this to inform developers that they are not fully
>complying to a changed contract?
>Still, for me it feels like the original interface should have included this
>and I think it would be nice if we have an exit strategy for this (and
>similar) situations where the original interface was wrong. I consider
>the solution that introduce an additional interface in the long term to be
>less than optimal. (Except if someone has a good explanation that I can
>give to new developers why we made that distinction in the first place.)
You can use the deprecation mechanism when you are ready to introduce
a new interface and deprecate the use of the old one (i.e. generate
a deprecation warning when an adapter is registered for the old interface).
Generating a deprecation warning in the case when something does not
provide/implement features newly introduced into the interface may
be expensive: you need to explicitly check any object providing the interface
whether it truely provides the added features as well.
We might want to implement something like version numbers for interfaces
in the future -- following the example of protocols ("HTTP/1.0" versus
"HTTP/1.1"). Then a class/instance may declare that it implements interface
"I" in version "V".
Then, we may issue deprecation warnings, when a too old interface is
Of course, adding version numbers to interfaces, is just a convention
to introduce new (but related) interfaces.
Zope3-dev mailing list