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 _______________________________________________ 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 )