Phillip, In my mind, the driving use-case for PEP 246 was to allow causual programmers to plug components together and have it 'just work'; it does this by enabling the component vendors to carry on a discussion via __adapt__ and __conform__ to work together. I was not picturing that your average developer would be using this sort of thing.
On Wed, Jan 12, 2005 at 09:57:07PM -0500, Phillip J. Eby wrote: | First, adapter abuse is *extremely* attractive to someone new to the | concept -- so from here on out I'm going to forget about the idea that we | can teach people to avoid this solely by telling them "the right way to | do it" up front. | | The second, much subtler point I noticed from your posts, was that | *adapter abuse tends to sooner or later result in adapter diamonds*. However, I'd like to assert that these cases emerge when you have a registry /w automatic transitive adaptation. These problems can be avoided quite easily by: - not doing transitive adaptation automatically - making it an error to register more than one adapter from A to Z at any given time; in effect, ban diamonds from ever being created - make it easy for a user to construct and register an adapter from A to Z, via an intermediate X, adapt.registerTransitive(A,X,Z) - if an adaptation from A to Z isn't possible, give a very meaningful error listing the possible pathways that one could build a 'transitive adaption', adaptation path', perhaps even showing the command that will do it: adapt.registerTransitive(A,B,C,Z) adapt.registerTranstive(A,Q,Z) adapt.registerTranstive(A,X,Z) The results of this operation: - most component vendors will use __adapt__ and __conform__ rather than use the 'higher-precedent' registry; therefore, transitive adaption isn't that common to start with - if two libraries register incompatible adpater chains during the 'import' of the module, then it will be an error that the casual developer will associate with the module, and not with their code - casual users are given a nice message, like "Cannot automatically convert a String to a File. Perhaps you should do a manual conversion of your String to a File. Alternatively, there happen to be two adaptation paths which could do this for you, but you have to explicitly enable the pathway which matches your intent: To convert a String to a File via StringIO, call: adapt.registerTranstive(String,StringIO,File) To convert a String to a File via FileName, call: adapt.registerTranstive(String,FileName,File)" | What that suggests to me is that it might well be safe enough in practice | to let new users of adaptation whack their hand with the mallet now and | then, given that *now* it's possible to give a much better explanation of | "as a" than it was before. By disabling (the quite dangerous?) transitive adaptation, one could guide the user along to the result they require without having them shoot themselves in the foot first. | What this also suggests to me is that maybe adaptation and interfaces are | the wrong solution to the problems we've been trying to solve with them | -- adding more objects to solve the problems created by having lots of | objects. :) I didn't see how your remaining post, in particular, Dylan's protocol was much different from an mixin/abstract-base-class. Regardless, getting back to the main goal I had when writing PEP 246 -- your alternative proposal still doesn't seem to provide a mechanism for component developers to have a dialogue with one another to connect components without involving the application programmer. Cheers! Clark _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com