[Zope-dev] internal improvements to zope.component Was: ZCA summary so far...

[Gary Poster]

On Dec 3, 2009, at 12:08 PM, Martijn Faassen wrote:

> Gary Poster wrote:
>> 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.
> 
> Sorry, that wasn't very clear. I just meant that we should improve the
> lookup API not waiting for underlying API changes to materialize. These
> processes should be decoupled. If from underlying API changes we come up 
> with even better lookup APIs, so be it.

Ah, I see (and I didn't before).  Yes.

>>> * 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.
> 
> Where is your pain point?

There are many concerns that my interviews raised.  I talked about them in my OSCON talk, and they are at the heart of my PyCon talk.  You and Chris appear to share somewhere between many and all of them, between you.  I don't have time for more details than that right now.

...

>>> * 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."
> 
> Sure, we don't want to drop support either. :)

My point is that I don't find net value in the names, especially adaptation, as I've said repeatedly.  I don't want them to be necessary in lower-level APIs that I teach and promote.  I'm happy to continue to have internals that can *support* APIs that use the "adapter" names.  I don't want them to *use* those names.

The confusion in message here I think is because of your next point, on which we disagree.

>>> * 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 don't want zope.component become a shell on some other package with a 
> better API. I know that that's often how we work, but I'd like to try to 
> make zope.component itself that better package.

I don't think we are at a point that debating this is worthwhile, at least from my perspective.  I still want to see what of my own pain points I can remove, without the constraint you describe.  I'll be better able to debate (or concede!) once I have done that.

>> 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 don't want this to be a "take it or leave it" situation. I'd like 
> there to be some commitment to making this package work for the whole 
> community. I do not want this to be another vision that in the end the 
> community can't use because we still depend on zope.component.

If the community *can't* use my work, then it is wasted.  I don't want that.  I want it to be valuable.  I especially want Launchpad to be able to use it easily, and we use a lot of Zope community packages.

That said, it's a risk one takes on projects like this sometimes.  I'll try to mitigate it.

Gary