Martijn Faassen wrote: > Thomas Lotze wrote: >> Martijn Faassen wrote: >>> * have dummy implementations in zope.interface that raise >>> NotImplementedError >> >> That would still introduce too many zope.component concepts into >> zope.interface IMO: obviously that of utilities as one of the dummy >> methods would bear that name, and those of named components and lookup >> contexts if the methods were to be specified by IInterface. > > I think having these markers is very important for code readability. > People reading the code will otherwise have no idea whatsoever where these > methods come from.
I see your point, but I have two objections: - The very concept of the ZCA introduces a related problem with code readability: just by reading the code that uses components you will never be able to tell where a particular adapter or utility comes from, or even what adapters or utilities you can hope to look up in the first place. So having to have some knowledge of the larger system that uses the interface mechanics isn't an entirely new thing, and having to learn about these two methods is a very small one-time effort compared to the "readability obstacles" that using the system thus entails. - As pointed out before, I consider it a goal to treat all uses of interfaces equally (which seems to me to be related to the effort to make interfaces more of a part of the language). By implementing stubs for `adapt` and `utility` (or specifying them in IInterface) we'd make the ZCA stand out as a particular use of interfaces. IMO, we serve those who seek to understand the API just as well by documenting the two methods as prominent examples of interface usage. I guess we should make a decision about the latter point of view before discussing a particular implementation strategy. > I'm not sure whether much of a general mechanism is really needed, after > all we already have monkey patching (um, sorry Tres, modifying a class). > I can see there being an API in zope.interface that allows one to plug > into .utility() and .adapt() If you're talking about the component hooks, then that's the part I hope to get rid of as it causes more trouble than it helps. (This is what I tried to point out in the message that started this thread.) >> parameter isn't even called 'default' but 'alternate' in >> Interface.__call__. The very name of the default argument is another >> thing that is sneaking from zope.component into zope.component. > > Let's deprecate 'alternate' and introduce 'default' then. Might actually > make the deprecation more easy.. I don't think so. We're going to deprecate not spelling out the name of the parameter, so it won't matter which name not to spell out. OTOH, we'll additionally have to deprecate the name `alternate` where it is used. I'm not sure whether we should make the name of that parameter consistent between zope.component and zope.interface, or leave it alone in order not to pretend the relation between the different implementations of adaptation to be stronger than it actually is. -- Thomas _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )