Re: internal improvements to zope.component Was: ZCA summary so far...

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  -  [email protected]
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 )