Paul Moore wrote:
> On 4/7/06, Eli Stevens (WG.c) <[EMAIL PROTECTED]> wrote:
>> It seems to me that now to get a duck-typed list, not only do you have
>> to implement all of special methods that define "listy-ness," you also
>> have to find the overloaded functions that are specialized for lists,
>> and register your own implementation (or an implementation specialized
>> for lists, if appropriate).
>
> Thanks for raising this - I have similar concerns, but I hadn't
> managed to focus them well enough to explain. This is exactly what has
> been bugging me.
>
> Paul.
I haven't looked at the actual posted examples yet so this is more an
overview of issues as I see them. I tend to lag in these more technical
threads, but here's the way I understand it so far.
In the sane transitive adaption thread I made the comment that there may
be a relationship between identifying "logical equivalence" and
adaptation, although I didn't explain what I meant by that.
First of all, weather your source object and your destination object
have all the same methods or not isn't an issue. In fact if they did,
you wouldn't need to adapt anything as duct typing would just work.
What is an issue is that the data they contain is translatable. Using
tuples and lists as an example:
(1,2,3) == [1,2,3] -> False; They are not equivalent.
But the data they contain is the same, and you can convert from one to
the other without any loss. So you can say they are logically equivalent.
A to B; B to C; and A == C
(1,2,3) <=> [1,2,3] -> True; They can be translated.
Python already treats tuples and lists as interchangeable in many cases.
They have one to one data mapping and they share methods that have the
same names and function. So duck typing works in many cases as is.
But what if they didn't map to each others data one for one, and/or had
different methods? They could still be "logically equivalent", but
simple duck typing wouldn't work, so you would need something more than
duck typing, ie.. an adapter, or a library factory functions, or have
each type be able to read every other type.
The first option adaptation could be just be a wrapper that substitutes
matching method names and/or acted as a go between to allow an object to
temporarily gain matching methods so duck typing would work on it.
The second option actually creates object B from object A.
Both of these need some sort of interface to choose the correct adapter
or converter.
The last one, having every object know how to read every other
"logically equivalent" object just isn't practical. But that doesn't
mean it can't act as if it can by calling a some common framework.
The "logically equivalent" requirement only applies to implicit
adaptation. With explicit (on request) adaptation, it could be assumed
that it is understood the result may not be reversible or may loose some
data as in converting floats to ints.
The real difficulty is in how to implement these concepts in a way that
can be extended and be useful in a broader range. An adapter need not
implement every method, but only needs to provide mappings to methods
that are missing and/or are different between two objects. Those
methods could reside in a common library and be identified dynamically
as they are needed or they could be pre-identified and registered as
sets for known objects.
Ideally once a library of adapter mappings is in place, creating and
adding new adapters wouldn't be that hard as many of the preexisting
methods could be reused.
This is about as far as I've gotten so far, so I'll have to leave
anything I missed or misunderstood to the experts and keep trying to
follow along as they try out the different ideas. :-)
Cheers,
Ron
_______________________________________________
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
