Chris McDonough wrote:
> Martijn Faassen wrote:
>> Chris McDonough wrote:
>>> I'll throw out the obvious...
>>> Why not subclass Interface in zope.component and make the required API 
>>> additions there?  If it were anybody but us thinking about doing this, 
>>> they'd 
>>> probably just subclass.
>> Because then we'd need to rebase all our interfaces to be able to use 
>> the new feature, making it pretty useless as a handy shortcut.
> I guess the counterargument is that you need to change your code anyway to 
> make 
> use of the new feature.  So what's the difference?

I'm a bit surprised I need to spell it out, so perhaps I am missing 

With your subclass proposal, if I use package a.b.c that defines an 
interface, and I import that interface and want to use the new feature, 
I'd need to change package a.b.c to make use of the new feature. That's 
a code change (changing the interface import), and a dependency change 
(making sure the new version of zope.component is in use), and a release.

I need to do that for all packages I import interfaces from. I need to 
*know* which packages have been updated or have things blow up on me. 
That's quite a hassle.

The end result would be that everybody ends up inheriting from the new 
zope.component Interface just to get access to the new methods 
everywhere, or that the new methods don't get uptake from users as 
nobody bothers to use the new API because it is too much work changing 
your dependencies.

If we change the Interface base class, I could use the new feature with 
any interface coming from anywhere. I'd only need to make sure that my 
own package depends on a newer version of zope.interface (or possibly a 
newer version of zope.component, depending on the way these methods are 



Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to