[Zope-dev] Interfaces vs ZCA concepts

[Thomas Lotze]

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