-----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 tsea...@palladion.com 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 - 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 )
