On Wed, Jan 12, 2005 at 01:15:20PM -0800, Guido van Rossum wrote:
| [Clark]
| > - add a flag to adapt, allowTransitive, which defaults to False
|
| That wouldn't work very well when most adapt() calls are invoked
| implicitly through signature declarations (per my blog's proposal).
Understood. This was a side-suggestion -- not the main thrust of my
response. I'm writing to convince you that automatic "combined"
adaptation, even as a last resort, is a bad idea. It should be
manual, but we can provide easy mechanisms for application developers
to specify combined adapters easily.
On Wed, Jan 12, 2005 at 02:57:11PM -0500, Clark C. Evans wrote:
| On Wed, Jan 12, 2005 at 10:16:14AM -0800, Guido van Rossum wrote:
| | But now, since I am still in favor of automatic "combined" adaptation
| | *as a last resort*
A few problems with automatic "combined" adaptation:
1. Handling the case of multiple adaptation pathways is one issue;
how do you choose? There isn't a good cost algorithem since the
goodness of an adapter depends largely on the programmer's need.
2. Importing or commenting out the import of a module that may seem
to have little bearing on a given chunk of code could cause
subtle changes in behavior or adaptation errors, as a new path
becomes available, or a previously working path is disabled.
3. The technique causes people to want to say what is and isn't
an adapter -- when this choice should be soly up to the
appropriate developers. I'd rather not have to standardize
that FileName -> File is a _bad_ adaption, but File -> String
is a good adaption. Or whatever is in vogue that year.
4. It's overly complicated for what it does. I assert that this is
a very minor use case. When transitive adaptation is needed,
an explicit registration of an adapter can be made simple.
My current suggestion to make 'transitive adaption' easy for a
application builder (one putting togeher components) has a few
small parts:
- If an adaptation is not found, raise an error, but list in
the error message two additional things: (a) what possible
adaptation paths exist, and (b) how to register one of
these paths in their module.
- A simple method to register an adaption path, the error message
above can even give the exact line needed,
adapt.registerPath(from=A,to=C,via=B)
- Make it an error to register more than one adapter from A
to C, so that conflicts can be detected. Also, registrations
could be 'module specific', or local, so that adapters used
by a library need necessarly not be global.
In general, I think registries suffer all sorts of namespace and
scoping issues, which is why I had proposed __conform__ and __adapt__
Extending registry mechanism with automatic 'transitive' adapters
makes things even worse.
Cheers,
Clark
--
Clark C. Evans Prometheus Research, LLC.
http://www.prometheusresearch.com/
o office: +1.203.777.2550
~/ , mobile: +1.203.444.0557
//
(( Prometheus Research: Transforming Data Into Knowledge
\\ ,
\/ - Research Exchange Database
/\ - Survey & Assessment Technologies
` \ - Software Tools for Researchers
~ *
_______________________________________________
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
