[Zope3-dev] Re: Providing flexible adapters

Shane Hathaway shane@zope.com
Tue, 26 Feb 2002 10:40:00 -0500


Steve Alexander wrote:
> If only there were not the constraint on the Adapter Service that you 
> provide an adapter between two particular interfaces...
> 
> Otherwise, I think what I've called IReferenceGenerator, below, is 
> really just a matter of registering an adapter to provide an IReference 
> for anything that it is given.
> 
> I can think of other scenarios where I'd want to provide generated 
> adapters, such as using TransWarp (or another generative programming 
> tool) with Zope 3.
> 
> Here's how I'd like to change the IAdapterService interface.
> This is what we have now. I've shortened the docstrings.

This seems like a good opportunity for me to talk about services versus 
utilities again.  I like your train of thought and I'd like to tell you 
where it leads my train of thought. :-)

Here's the situation: we have a new kind of functionality we're 
considering.  We know mostly how it will work but we don't know what the 
edge cases will be.  We know that we'll need to be able to configure 
which kinds of references are generated for different types of objects, 
and we think we might be able to simply use the adapter registry as the 
configuration mechanism.  But we can't be sure.

This is a pattern that happens over and over again in software 
development.  We could just write the code, but we want to make it 
reusable.  How do we do both?

Zope 3's answer is to make a reference generation utility.  It would be 
a very, very simple utility that might just look up an adapter.  If we 
later decide that the adapter registry is sufficient, we can just leave 
it that way.  If we instead decide that generating a reference depends 
on not just the interfaces of the object, but also the interfaces of the 
object's context (or something else), we can make a new service.

Maybe this is the pattern: when you've made a decision, you write 
software, but when you can't make a decision, you write configuration, 
then write software that implements the decisions you might make.

> This could be implemented by a small specialisation of the IToIRegistry.
> If the IToIRegistry finds no better match for (ob_interface, provide), 
> it returns the match for (ob_interface, None), if there is one.

Actually, FYI you can already register an adapter that adapts anything, 
using the value "None" as the object's interface.

Shane