...from my perspective. = Things vaguely approaching consensus = == General == There's a consensus that changes to the ZCA need to be backwards compatible. The practical definition of that varies for different people. == Syntactic == === Tuple multi-adaptation === Example: IFoo((bar, baz)) == z.c.getMultiAdapter((bar, baz), IFoo) - It has the most consensus of any proposed change so far. - It is concerning because it breaks backwards compatibility in two real world use cases from the very small set of Zope users who actually watch zope-dev. There is a workaround spelling at least, but it is ugly (i.e., what was ``IFoo((bar, baz))`` will need to become ``IFoo(((bar, baz),))``). - It is easier to remember than ``z.c.getMultiAdapter((bar, baz), IFoo)`` (I always have to look up the order of arguments for getMultiAdapter myself) but not as easy to remember as ``IFoo(bar, baz)``. It introduces yet another spelling of the same thing (e.g., ``IFoo(bar)`` is the same as ``IFoo((bar,))``. == Utilities available from interfaces == As far as I can tell, no one is against this generally, and several people are for it. Some people are against the syntax that has been proposed for this that merges utilties and adapters (see "No consensus" section below). An alternate syntax was proposed involving a ``utility`` callable. This made the most sense when it was paired with an ``adapters`` (or ``factory`` or ``new`` or ``instance`` or ``create``) callable, which contradicts the consensus of the "tuple multi-adaptation" section above. = No consensus AFAICT = - Utilities and adapters should be merged. - We care significantly about new and casual users and perceive that the current API does not serve them well. - Adapters are usually used as factories, and utilities are used as instances, and it is valuable to present them that way. Related: the term "adapter" buys us little and costs us more than nothing among new and casual users. = Rejected = - Utilities should be called singletons.
My $.02 is here: http://www.plope.com/Members/chrism/zca_thoughts_summary Gary Poster wrote:
...from my perspective.
= Things vaguely approaching consensus =
== General ==
There's a consensus that changes to the ZCA need to be backwards compatible. The practical definition of that varies for different people.
== Syntactic ==
=== Tuple multi-adaptation ===
Example: IFoo((bar, baz)) == z.c.getMultiAdapter((bar, baz), IFoo)
- It has the most consensus of any proposed change so far.
- It is concerning because it breaks backwards compatibility in two real world use cases from the very small set of Zope users who actually watch zope-dev. There is a workaround spelling at least, but it is ugly (i.e., what was ``IFoo((bar, baz))`` will need to become ``IFoo(((bar, baz),))``).
- It is easier to remember than ``z.c.getMultiAdapter((bar, baz), IFoo)`` (I always have to look up the order of arguments for getMultiAdapter myself) but not as easy to remember as ``IFoo(bar, baz)``. It introduces yet another spelling of the same thing (e.g., ``IFoo(bar)`` is the same as ``IFoo((bar,))``.
== Utilities available from interfaces ==
As far as I can tell, no one is against this generally, and several people are for it. Some people are against the syntax that has been proposed for this that merges utilties and adapters (see "No consensus" section below). An alternate syntax was proposed involving a ``utility`` callable. This made the most sense when it was paired with an ``adapters`` (or ``factory`` or ``new`` or ``instance`` or ``create``) callable, which contradicts the consensus of the "tuple multi-adaptation" section above.
= No consensus AFAICT =
- Utilities and adapters should be merged.
- We care significantly about new and casual users and perceive that the current API does not serve them well.
- Adapters are usually used as factories, and utilities are used as instances, and it is valuable to present them that way. Related: the term "adapter" buys us little and costs us more than nothing among new and casual users.
= Rejected =
- Utilities should be called singletons.
_______________________________________________ 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 )
On Dec 3, 2009, at 1:54 AM, Chris McDonough wrote:
My $.02 is here:
I was going to comment on your blog, even though it was separate from the mailing list, but then I couldn't register an account, so here I am. I agree with a decent chunk of what you say. I guess my experiences working with new and casual ZCA users in Launchpad are somewhat similar to your BFG experiences. I'm very interested in working on changes in the underlying registry. Like you (I think), I'd also like to support the ability for using classes and abcs for specs. I have some work in that direction. I also want a better debugging API, which I have also investigated. We might disagree on the specifics, but it sounds like we're similar in broad desires there. I also agree with many of your perceptions of what we have: the experimental package I have started that subsumes the jobs of zope.interface and zope.component is called "pluggable," which echoes one of your points. I don't think replacing these packages is a practical way forward, but it helps me think and imagine. I think that moving forward might be easiest to do by making the adapter registry pluggable in zope.interface and zope.component, and working on this in another package. At that point, interested users of zope.interface and zope.component could choose to use our registry (and perhaps it might evolve to become the "blessed" registry at some point); and we could provide alternative ways of using the package, separate from zope.component and zope.interface. We should collaborate. In my "copious spare time" I would like to call you and see if you and I can at least agree on some experiments in this direction. I'd like it if my work had some chance of uptake in BFG. 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. Gary
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'd like to see some underlying refactorings in zope.component/zope.interface. * I'd also like to see a better registration API * documenting this clearly (and perhaps in advance of any actual work) is important. * I'd like to keep zope.interface and zope.component backwards compatible and still benefit from the improvements. * Therefore, any rethink of the internals can be substantial but not so fundamental as to drop interfaces or 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 *also* would like to take a range of optional dependencies out of zope.component, however. The ZCML directive implementations in particular. * 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. Regards, Martijn
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
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.
* 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?
* 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.
Sure, experiments are fine.
* 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."
Sure, we don't want to drop support either. :)
* 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 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.
* 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.
I think Chris McDonough shares this problem, as he already forked the directive implementations. Probably grokcore.component could be a bit nicer too. Regards, Martijn
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
Hey, Thanks for doing this summary! Gary Poster wrote: [snip]
== Utilities available from interfaces ==
As far as I can tell, no one is against this generally, and several people are for it. Some people are against the syntax that has been proposed for this that merges utilties and adapters (see "No consensus" section below). An alternate syntax was proposed involving a ``utility`` callable. This made the most sense when it was paired with an ``adapters`` (or ``factory`` or ``new`` or ``instance`` or ``create``) callable, which contradicts the consensus of the "tuple multi-adaptation" section above.
It's clear that a unification of adaptation and utility lookup in the API as I discussed is going much too far for many people. So I've given up on that. (we can always take it up again in some other context in the future) Regards, Martijn
participants (3)
-
Chris McDonough -
Gary Poster -
Martijn Faassen