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 move 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 convention, 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 Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
