On 5/7/09 6:17 PM, Shane Hathaway wrote:
> Chris McDonough wrote:
>> On 5/7/09 5:28 PM, Shane Hathaway wrote:
>>>> Or just make it simple, and return a tuple of (callback,
>>>> discriminator). Or a sequence of like [(callback, discriminator),
>>>> (callback, discriminator), <etc>], as you say.
>>> True. Is it time to write repoze.configuration? ;-)
>> Ha.. sadly, already done, mostly:
>> http://docs.repoze.org/plugin/config.html
>> http://svn.repoze.org/repoze.plugin/trunk/
>> I haven't really expected it to see the light of day but it does
>> indeed work, eschews zope.schema and returns those tuples.
> Oh I see... the component registry you wrote also acts as a simple
> mapping. That's a good solution. Your component registry is also
> impressively small.

I actually think that maybe (like the split between zope.component and 
zope.configuration), repoze.plugin maybe should offer up just a *plain* 
dictionary on the context as something that could be used as a registry and 
the adaptery bits out into some consumer package (which might construct its own 
context type with an explicit adapter registry on it and pass it in, etc).

> It looks like you chose not to use zope.interface at all, but that's too
> radical for me. :-) I imagine a plugin system that can rely on either
> zope.interface or ABCs would have a much better chance at wide adoption.

Interfaces are always treated as plain-old markers during adaptation anyway in 
zope.component at least delta an "IRO".  (BTW, I actually consider an IRO an 
anti-use-case, at least if the MRO is also used by default by the adapter 
machinery, which currently in zope.component it is.)

r.plugin can use zope.interface Interface objects as markers too.  It doesn't 
require them to be anything in particular, just hashable.   It could also use 
objects that are of a particular abstract base class.  It's all just 
r.plugin doesn't care.

People are often confused about the duality of zope.interface Interface objects 
being used as markers during adaptation as well as being used as a mechanism to 
describe an API.  Personally, I think it should be possible to keep the two 
concepts logically distinct in any given application.  I don't really have a 
sense of how abstract base classes would fit in here.

- C
Repoze-dev mailing list

Reply via email to