Re: Interfaces vs ZCA concepts

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  -  [email protected]
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 )