Re: Interfaces vs ZCA concepts

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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'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()

I don't see any win for the "generic" extensions either:  we already
know *exactly* what two methods we want to use, and have no use cases at
all for adding any others.

>>> * have that NotImplementedError say to look for implementations in
>>> zope.component
>> I would actually like a mechanism that doesn't care about what package
>> will inject which pieces of API. Do you think such generality is asking
>> too much (at least at this point in time)?
> 
> I think it will be less clear compared to the methods being there and 
> saying they're injection points intended to be overwritten.

- -1 to any docstring / exception method which points outside the
zope.itnerface package.  There is a perfectly reasonable "default"
implementation anyway (in the absence of any hooks):

- - IFoo.adapt(context) raises LookupError, unless the context
  provides IFoo, in which case it returns context.

- - IFoo.adapt(context, default=default) returns default unless context
  provides IFoo, in which case it returns context.

- - IFoo.utility() raises LookupError.

- - IFoo.utility(default=default) returns default

I would much rather keep a "hook registration" API in the interface
class for these methods than obscure their origin semantics via a monkey
patch.

>>> Did you make an implicit 'default' deprecated on __call__ yet by the way?
>> Not yet; the other issue looked more interesting so far ;o) BTW, that
>> 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..

Note that Interface.__call__ is not documented at all as an API::

 $ grep __call__ src/zope/interface/interfaces.py
 $

I think we should just rename the argument without any deprecation.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          [email protected]
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkspVZYACgkQ+gerLs4ltQ52fACcC3Pd8uGvTzjkKwmTX97PrQaf
oxkAoLoA1lRxpPA6HpQYQtifxQBM8sbF
=jebA
-----END PGP SIGNATURE-----

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