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 something. 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 implemented). Regards, Martijn