Chris McDonough wrote:
> Thomas Lotze wrote:
>> Because then, if you use third-party code that uses
>> zope.interface.Interface and other code (third-party or your own) that
>> uses the subclassed interfaces, you'll have to deal with both types at
>> the same time in your client code. You could use the new API on some
>> interfaces but not on others, possibly on the same line of code. How
>> readable or maintainable would such code be?
> I'm not sure, but if we had it to do all over again, this would be an
> obvious solution. It would be the work of maybe two days to convert all
> "ZTK" packages to use a z.c.interface.Interface, and any existing package
> would need to be touched anyway to use .adapt and .utility. So it bears
> some weight I think, even if it is eventually rejected.
It does certainly bear some weight as one possibility to be considered.
However, my point wasn't so much about converting a limited existing
amount of code; you're obviously right about having to touch that anyway
in order to use the new methods.
My objection is this: If we go to the trouble of implementing basic
interfaces in zope.interface plus derived ones with component lookup
capabilities in zope.component and keep both around for their respective
reasons of existence, then it is expected that there will be code that
uses both types of interfaces for these very reasons (and maybe other
types which have other added behaviour). Such code would become a lot less
maintainable since you'd never know whether a given interface has a
particular method just because the one next to it does.
OTOH, registering all behaviour an application needs onto the same
interface type doesn't create that problem. As long as you're familiar
with the application at large, you will know for every interface that
occurs in it which methods is has, how they need to be called and what
their semantics are.
Also, subclassing for adding behaviour introduces the typical problems of
hierarchies and tight coupling. This isn't a practical problem as long as
we only ever talk about adaptation as the only use of interfaces, but I'm
trying to discuss "interfaces as a language feature" with a greater set of
possible use cases.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -