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