On Dec 3, 2009, at 10:51 AM, Martijn Faassen wrote:
Gary Poster wrote: [snip]
I personally think these efforts do not make the potential consensus on ``adapt`` and ``utility`` methods any less interesting: they would be a concrete win for my users.
I agree with much of what Gary is saying here.
My ideas:
* I'd like us not to make any lookup API improvements on looking up things dependent on underlying refactorings.
I didn't follow this until I squinted at it and came up with "I'd like us not to make any API improvements on looking up things dependent on underlying refactorings." That sounds reasonable.
* I'd like to see some underlying refactorings in zope.component/zope.interface.
A broad agreement, but an agreement nonetheless.
* I'd also like to see a better registration API
I don't have that pain point ATM, but I can vaguely see where one might.
* documenting this clearly (and perhaps in advance of any actual work) is important.
+1 on documenting. -1 on not allowing some experiments to happen first.
* I'd like to keep zope.interface and zope.component backwards compatible and still benefit from the improvements.
+1
* Therefore, any rethink of the internals can be substantial but not so fundamental as to drop interfaces or the ideas of adaptation and utilities.
I'm +1 on that as long as it can be rephrased to "...can be substantial but not so fundamental as to drop interfaces or the *support for* the ideas of adaptation and utilities."
* Preferably I would like these things to take place in zope.component and/or zope.interface. Experimental packages are all right, I guess, but I wouldn't want them to be permanent. Let's keep the user community together on this one, please.
I am interested in a package that gives the pluggable functionality I want but that does not depend on zope.component, but that zope.component can or does depend on. I am not a fan of design by committee. I do think a community ("committee") often has better ideas than a single person. Certainly I feel comfortable saying that when the single person is myself. I reconcile these positions by feeling that a very small number of people should design packages initially. Then the community can take them, take them and modify them, or leave them (ideally learning from them).
* I *also* would like to take a range of optional dependencies out of zope.component, however. The ZCML directive implementations in particular.
I don't have that pain point ATM, but I can vaguely see where one might.
* but I'd be fine if we got a better API and implemented the old APIs on top of these.
* and we might eventually deprecate the old APIs.
Agreed. Gary