[Python-3000] Iterators for dict keys, values, and items == annoying :)
Benji York
benji at benjiyork.com
Fri Mar 31 16:30:43 CEST 2006
Alex Martelli wrote:
> If the framework consuming X requested adaptation-to-X on all objects
> it's passed,
That's not generally the way Zope 3 does it (and doesn't sound like a
good idea to me).
There are three ways (as I see it) adaptation is used in Z3. First, the
traditional idea of an "adapter", in which something has the right
state, but the wrong interface. That form of adaptation is used when
plugging different components together (whether they are Z3 or come from
other projects). In that way of using adaptation a
function/method/whatever wants things that act in a particular way (duck
typing). If I, as the user of the interface, have something I want to
pass in that doesn't match I it to the appropriate interface the burden
is on me to create something that matches expectations. People do that
all the time today without an interface/adaption framework, they just
write code that takes one thing and builds another.
Greg Ewing wrote:
> This is the part that bothers me, I think. It
> seems like all these adaptation requests would
> be a huge burden on the framework developer.
Not in the above scenario, when using adapters like that the burden is
on the user. That might sound like a bad thing, but if they're
exclusively using your library, they already have objects of the
necessary type, if not they have an adaptation framework to help them do
something they'd have to do anyway.
The second way adaptation is used is as a general lookup facility. Say
that I have a user object and I want to know their security information.
Instead of building an API for looking up security descriptions from a
user name that I have to pull out of the user object, I could instead
register and adapter from IUser to ISecurityInfo, now I don't need any
new APIs, I just so sec_info = ISecurityInfo(the_user). This form of
adaptation is good for the "I have something and want more information
about it" use case. It also adds some flexibility, the workings of the
adapter can change without having to change all the client code as you'd
have to do if you changed (for example) the parameters an API expected.
The third way it's used is to make systems pluggable. You mentioned
PyGUI, so say you had a schema describing a data entry form. You could
use adaptation to decide which GUI widget would be used for each field.
Looping over the form fields and adapting each to IWidget and getting
back a TextField for a string, CheckBox for a boolean, etc. Then if the
user has a nice TextField object with spell checking, they could just
plug in a different adapter and all their fields would get the new
widget without PyGUI having to support a plug-in framework.
> In PyGUI, for example, I currently have about
> 2 or 3 dozen classes. Should I be defining and
> registering a formal protocol for every one of
> those?
Unless PyGUI wants to use the interfaces for something, probably not.
Another theme of Zope 3 is to use other project's code instead of
reinventing the wheel. If we want to use a third-party class with
adaptation, we can (externally to the class) assert that it conforms to
a particular interface.
I don't intend to bore people with a study of adaptation in Zope 3, but
instead am attempting to echo Alex's realization that once you have the
simple tools of adaptation in mind (much like other practices like OO or
data-driven programming) you start to recognize places where they help
you solve problems in better ways.
--
Benji York
More information about the Python-3000
mailing list