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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
