Thomas Lotze wrote: [snip]
- 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.
I think the cost of introducing some dummy methods that document this is very low, and we should do it. Other readability obstacles aren't an excuse to create more. :)
- 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'd say the best way of documenting them is by putting a few stubs in the code. That way they're hard to miss. It'll also be easy to understand why they're *not* working if zope.component isn't installed. I really see the cost of doing this as pretty low - it's not like we're putting actual real implementations in there, just information, so I see this primarily as a form of documentation. [snip my argument that monkey patching the methods in seems a decent way to do it]
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.)
If they can be replaced by a simple assignment to __call__ that might be clearer. I am just talking about not inventing some kind of sophisticated way to put these methods in. I think the most clearly readable code would be this (if this is indeed possible due to the weirdness of Interface): from zope.interface import Interface Interface.__call__ = our_call Interface.adapter = our_adapter Interface.utility = our_utility I do think it's iportant that Interface defines these methods, if only to raise NotImplementedError.
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.
Definitely make it consistent. Anything else is much harder to learn and remember. While this may be a signal "something different is going on", it's in my mind an actively harmful one. We already signal something different may happen as it's after all a different method. Regards, Martijn