Hi there,

Reading the thread Chris McDonough started (and ended) about modifying 
the way utility registration works reminded me of the following 
thinking. It's quite independent and probably even antithetical to 
Chris's approach as it uses interfaces, but that's fine.

The goal is to make it easier to look up certain componenty things. The 
goal is to have to import from "zope.component" as little as possible 
for lookups. Just import interfaces and you'll be done. I think it makes 
sense to make the lookup operation disappear into the "language" as much 
as we can make them.

I know we've had this kind of discussion before, but let's get something 
working this time around. So I'm also looking for volunteers to help out 
with the implementation.

I'm going to ignore registration APIs for now in this discussion. While 
they can be improved too, we have ZCML and martian-style registration 
systems that can handle that ok. Let's focus on lookup APIs first.

We have a nice way to look up a single adapter:

from foo import IFoo


Unfortunately, this breaks down when you want to look up a multiadapter:

from foo import IFoo
from zope import component

component.getMultiAdapter((x, y), IFoo)

That's an extra import and a lot more typing.

We also have it break down when you want to look up a utility:

from zope import component


So let's look at ways to hook this up to interfaces.



Adapter with default:

IFoo(x, default=default)

So far it's all supported. (I think. It's hard to find the code that 
supports this.. hints?)

Named adapter:

IFoo(x, name='something')


IFoo.multi(x, y)

Multiadapter with default:

IFoo.multi(x, y, default=default)

Named multiadapter:

IFoo.multi(x, y, name='something')



[or possibly IFoo() instead?]

Utility with default:


[or IFoo(default=default)?]

Named utility:


[or IFoo(name='something')?]

As a final thought, I don't like having to import 'implements' from 
zope.interface either. Since we're moving to Python 2.6 which supports 
class decorators, I'd like to see something like this become possible:

class Foo(object):

I know Jim had some objections towards implementation of this in an 
earlier discussion, but later changed his mind. So I'm going to look at 
Jim for hints about implementing this. :)

If we do well we might all have this for Christmas. :)




Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to