Mailing List Archive: Zope: Dev

split out zope.component "mechanics" into a separate package (was Re: improving the utility and adapter lookup APIs)

Index | Next | Previous | View Threaded

chrism at plope

Nov 25, 2009, 2:08 PM

Post #1 of 5 (695 views)
Permalink

split out zope.component "mechanics" into a separate package (was Re: improving the utility and adapter lookup APIs)

Chris McDonough wrote:
>> If some set of ZCA APIs made it the responsibility of the *caller* to invoke
>> the adapter with arguments would go a long way between normalizing the
>> difference between utilities and adapters (because they would essentially then
>> be the same thing).

The very core mechanics of how a component registry behaves resides almost
entirely in the zope.component.registry module.

It would be useful to split these core mechanics into a separate package.
Here's why:

- The zope.component module carries along an expectation of a particular global
API. This global API is not required to use the mechanics of the underlying
registry machinery.

- The zope.component package has a number of features that are irrelevant
to the operation of the core registry itself, such as persistence and
security.

- The registry itself is useful outside the context of the zope.component API
package; the API is essentially just "candy" on top of the registry itself.

I have created such a package at http://svn.zope.org/Sandbox/chrism/zope.registry

It contains an implementation of the registry and the tests for the registry
object. It depends on zope.interface and zope.event. I'd like to actually
remove the zope.event dependency and release a newer version of zope.event that
uses a global inside zope.registry as the list of registered object (reverse
the dependency).

After that's done, I'd suggest we make zope.component depend on zope.registry.

At this point, people can innovate with their own APIs to the registry object
as necessary; they needn't carry along the baggage of the expecation of the
older zope.component API working in their app.

Thoughts?

- C

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

gary.poster at gmail

Nov 25, 2009, 2:36 PM

Post #2 of 5 (653 views)
Permalink

Re: split out zope.component "mechanics" into a separate package (was Re: improving the utility and adapter lookup APIs) [In reply to]

On Nov 25, 2009, at 5:08 PM, Chris McDonough wrote:

> Chris McDonough wrote:
>>> If some set of ZCA APIs made it the responsibility of the *caller* to invoke the adapter with arguments would go a long way between normalizing the difference between utilities and adapters (because they would essentially then be the same thing).
>
> The very core mechanics of how a component registry behaves resides almost entirely in the zope.component.registry module.
>
> It would be useful to split these core mechanics into a separate package. Here's why:
>
> - The zope.component module carries along an expectation of a particular global
> API. This global API is not required to use the mechanics of the underlying
> registry machinery.
>
> - The zope.component package has a number of features that are irrelevant
> to the operation of the core registry itself, such as persistence and
> security.
>
> - The registry itself is useful outside the context of the zope.component API
> package; the API is essentially just "candy" on top of the registry itself.
>
> I have created such a package at http://svn.zope.org/Sandbox/chrism/zope.registry
>
> It contains an implementation of the registry and the tests for the registry object. It depends on zope.interface and zope.event. I'd like to actually remove the zope.event dependency and release a newer version of zope.event that uses a global inside zope.registry as the list of registered object (reverse the dependency).
>
> After that's done, I'd suggest we make zope.component depend on zope.registry.
>
> At this point, people can innovate with their own APIs to the registry object as necessary; they needn't carry along the baggage of the expecation of the older zope.component API working in their app.
>
> Thoughts?

FWIW, it's not of a lot of interest to me. I'm interested in changing things at a lower level. However that works, if I manage to build zope.component backwards compatibility as an add-on then I'll have to worry about all of the bits in zope.component, not just this.

Gary
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

faassen at startifact

Nov 27, 2009, 2:53 AM

Post #3 of 5 (635 views)
Permalink

Re: split out zope.component "mechanics" into a separate package (was Re: improving the utility and adapter lookup APIs) [In reply to]

Chris McDonough wrote:
> Chris McDonough wrote:
>>> If some set of ZCA APIs made it the responsibility of the *caller* to invoke
>>> the adapter with arguments would go a long way between normalizing the
>>> difference between utilities and adapters (because they would essentially then
>>> be the same thing).
>
> The very core mechanics of how a component registry behaves resides almost
> entirely in the zope.component.registry module.
>
> It would be useful to split these core mechanics into a separate package.
> Here's why:
>
> - The zope.component module carries along an expectation of a particular global
> API. This global API is not required to use the mechanics of the underlying
> registry machinery.
>
> - The zope.component package has a number of features that are irrelevant
> to the operation of the core registry itself, such as persistence and
> security.
>
> - The registry itself is useful outside the context of the zope.component API
> package; the API is essentially just "candy" on top of the registry itself.
>
> I have created such a package at http://svn.zope.org/Sandbox/chrism/zope.registry
>
> It contains an implementation of the registry and the tests for the registry
> object. It depends on zope.interface and zope.event. I'd like to actually
> remove the zope.event dependency and release a newer version of zope.event that
> uses a global inside zope.registry as the list of registered object (reverse
> the dependency).
>
> After that's done, I'd suggest we make zope.component depend on zope.registry.
>
> At this point, people can innovate with their own APIs to the registry object
> as necessary; they needn't carry along the baggage of the expecation of the
> older zope.component API working in their app.

One of my first responses would be some worry about zope.component
growing a *new* dependency. The goal of zope.component is that it's one
of those packages with only a few...

I'm trying to see who would be using zope.registry for what exactly.
Would it be much harder to experiment with these new APIs on top of
zope.component? You'll get a bit more baggage, but the minimal
dependency story should be quite small already. I'd rather get some of
the additional dependencies (that have a lot to do with supporting ZCML)
out of it, instead of moving its core functionality out.

You factored various related things together - perhaps it would make
sense to do this refactoring within zope.component?

I'm +1 on making zope.event part of zope.component and deprecating
zope.event.

Speculating, would it instead make sense to move zope.registry
functionality into zope.interface? The only additional dependency is
zope.event. At first glance the answer would be "no" as it really
introduces various component architecture concepts...

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

chrism at plope

Nov 27, 2009, 9:45 AM

Post #4 of 5 (635 views)
Permalink

Re: split out zope.component "mechanics" into a separate package (was Re: improving the utility and adapter lookup APIs) [In reply to]

Martijn Faassen wrote:
> Chris McDonough wrote:
>> Chris McDonough wrote:
>>>> If some set of ZCA APIs made it the responsibility of the *caller* to invoke
>>>> the adapter with arguments would go a long way between normalizing the
>>>> difference between utilities and adapters (because they would essentially then
>>>> be the same thing).
>> The very core mechanics of how a component registry behaves resides almost
>> entirely in the zope.component.registry module.
>>
>> It would be useful to split these core mechanics into a separate package.
>> Here's why:
>>
>> - The zope.component module carries along an expectation of a particular global
>> API. This global API is not required to use the mechanics of the underlying
>> registry machinery.
>>
>> - The zope.component package has a number of features that are irrelevant
>> to the operation of the core registry itself, such as persistence and
>> security.
>>
>> - The registry itself is useful outside the context of the zope.component API
>> package; the API is essentially just "candy" on top of the registry itself.
>>
>> I have created such a package at http://svn.zope.org/Sandbox/chrism/zope.registry
>>
>> It contains an implementation of the registry and the tests for the registry
>> object. It depends on zope.interface and zope.event. I'd like to actually
>> remove the zope.event dependency and release a newer version of zope.event that
>> uses a global inside zope.registry as the list of registered object (reverse
>> the dependency).
>>
>> After that's done, I'd suggest we make zope.component depend on zope.registry.
>>
>> At this point, people can innovate with their own APIs to the registry object
>> as necessary; they needn't carry along the baggage of the expecation of the
>> older zope.component API working in their app.
>
> One of my first responses would be some worry about zope.component
> growing a *new* dependency. The goal of zope.component is that it's one
> of those packages with only a few...
>
> I'm trying to see who would be using zope.registry for what exactly.
> Would it be much harder to experiment with these new APIs on top of
> zope.component? You'll get a bit more baggage, but the minimal
> dependency story should be quite small already. I'd rather get some of
> the additional dependencies (that have a lot to do with supporting ZCML)
> out of it, instead of moving its core functionality out.

I guess this was just a way of trying to draw a line between "the component
architecture" (and the conceptual baggage which surrounds it) and useful
machinery that currently is hidden inside of it that really should have a life
of its own. It's obviously not the only way to do that.

It tries to address the following problem.

Currently people seem to get wrapped around the axle and confused by the
purpose of "the ZCA", which currently implies at least two different things:

- Machinery to perform complex registrations and lookups using interfaces
in the form of a registry.

- A global API that presents a view of the world: "there are these things
called utilities and adapters, and this API is how you do adaptation and
utility lookup".

These two things are conceptually distinct.

It shouldn't be necessary to need to understand the concept of "utility" and
"adapter" to use a registry. A registry is just machinery that uses interfaces
as registration markers for the benefit of later arbitrary lookups, not
necessarily just for "finding utilities" or "finding and calling adapter
factories". For instance, you might use the registry to register some callable
that accepts *no* arguments with, say, two "requires" arguments. You shouldn't
need to call this an "adapter", because it's not one; you just want to register
something and get it back when you ask nicely.

The API of a registry should be able to evolve separately from the API of its
consumers (the global ZCA API is only one consumer). The current registry API
permits the concepts of utility and adapter to bleed into the implementation,
but this needn't be the case forever. We could provide (and document) a very
simple registry base class with a normalized API that didn't have any of this
conceptual baggage; it would be extremely popular, I think.

Likewise, it should be possible to use a different registry implementation to
service the ZCA global API. This is possible right now via
getSiteManager.sethook, of course.

> You factored various related things together - perhaps it would make
> sense to do this refactoring within zope.component?
>
> I'm +1 on making zope.event part of zope.component and deprecating
> zope.event.
>
> Speculating, would it instead make sense to move zope.registry
> functionality into zope.interface? The only additional dependency is
> zope.event. At first glance the answer would be "no" as it really
> introduces various component architecture concepts...

It might make sense to me to put a very simple component registry in
zope.interface: it already has the concept of "adapter" baked in.

- C
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

faassen at startifact

Nov 28, 2009, 3:25 AM

Post #5 of 5 (640 views)
Permalink

Re: split out zope.component "mechanics" into a separate package (was Re: improving the utility and adapter lookup APIs) [In reply to]

Chris McDonough wrote:
[snip]
> It tries to address the following problem.
>
> Currently people seem to get wrapped around the axle and confused by the
> purpose of "the ZCA", which currently implies at least two different things:
>
> - Machinery to perform complex registrations and lookups using interfaces
> in the form of a registry.
>
> - A global API that presents a view of the world: "there are these things
> called utilities and adapters, and this API is how you do adaptation and
> utility lookup".
>
> These two things are conceptually distinct.
>
> It shouldn't be necessary to need to understand the concept of "utility" and
> "adapter" to use a registry. A registry is just machinery that uses interfaces
> as registration markers for the benefit of later arbitrary lookups, not
> necessarily just for "finding utilities" or "finding and calling adapter
> factories". For instance, you might use the registry to register some callable
> that accepts *no* arguments with, say, two "requires" arguments. You shouldn't
> need to call this an "adapter", because it's not one; you just want to register
> something and get it back when you ask nicely.

Agreed, but isn't this registry in zope.interface already? I mean
zope.interface.adapter.AdapterRegistry? I've used this for the
"not-really-adapting-as-I-don't-want-to-call" in a library of mine
recently (traject).

You factored out the registry functionality, but there are still plenty
of references to utilities in it, for instance. As far as I understand
it that would be putting too much into zope.registry already?

> The API of a registry should be able to evolve separately from the API of its
> consumers (the global ZCA API is only one consumer). The current registry API
> permits the concepts of utility and adapter to bleed into the implementation,
> but this needn't be the case forever. We could provide (and document) a very
> simple registry base class with a normalized API that didn't have any of this
> conceptual baggage; it would be extremely popular, I think.

> Likewise, it should be possible to use a different registry implementation to
> service the ZCA global API. This is possible right now via
> getSiteManager.sethook, of course.
>
>> You factored various related things together - perhaps it would make
>> sense to do this refactoring within zope.component?
>>
>> I'm +1 on making zope.event part of zope.component and deprecating
>> zope.event.
>>
>> Speculating, would it instead make sense to move zope.registry
>> functionality into zope.interface? The only additional dependency is
>> zope.event. At first glance the answer would be "no" as it really
>> introduces various component architecture concepts...
>
> It might make sense to me to put a very simple component registry in
> zope.interface: it already has the concept of "adapter" baked in.

Yeah, I think this makes more sense.

So, we have a number of projects:

* interface API - the stuff around calling interface I sketched out
elsewhere. I think this is relatively low-hanging fruit. On the other
hand it breaks backwards compatibility. I wouldn't want this project to
depend on the other improvements, and I don't think it has to, so I'd
like to see this as zope.component 4.0.

* improving and move code that's general enough from zope.component into
zope.interface. What this would look like I'm not quite sure about yet,
as zope.registry at first glance contains a lot of knowledge about
utilities and such still. There are backwards compatibility issues
surrounding persistence but hopefully less around the APIs themselves.

* an improved registration API for zope.component. This would affect a
lot of code that does registration.

Documentation projects should go along with all of those.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads