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 )
