On Friday 21 June 2002 07:52 pm, David Abrahams wrote: ...
Such a strong endorsement from you made me go take a cursory look; I
From: "Alex Martelli"
I'd be -1 on this in its current form. It seems like an intrusive mechanism in that it forces the adapter or the adaptee to know how to do the job.
That's point (e) in the Requirements of the PEP:
""" e) When the context knows about the object and the protocol and knows how to adapt the object so that the required protocol is satisfied. This could use an adapter registry or similar method. """
However, do notice that even in its present form it's WAY less invasive than C++'s dynamic_cast<>, which ONLY allows the _adaptee_ to solve
Oh, sorry I missed that. things --
and in a very inflexible way, too. With dynamic_cast there's no way the "protocol" can noninvasively "adopt" existing objects, nor can an object have any say about it (e.g. how to disambiguate between multiple inheritance cases). QueryInterface does let the adaptee have an explicit say, but still, the adaptee is the only party consulted.
I wasn't trying to spark a comparison with C++ here, nor was I talking about runtime-dispatched stuff in C++. I'm not even sure I would call dynamic_cast<> a candidate for this kind of job, at least, not by iteself. I was thinking of the use of template specialization to describe the relationship of a type to a library, e.g. specialization of std::iterator_traitslibA::some_class by libB, which makes libA::some_class available for use as an iterator with the standard library (assuming it has some appropriate interface).
Only Haskell's typeclass, AFAIK, has (among widely used languages and objectmodels) a smooth way to allow noninvasive 3rd party post-facto adaptation (and another couple of small gems too), but I guess it has an easier life because it's compile-time rather than runtime.
IIUC the same kind of thing can be implemented in C++ templates, if you know where to look. There's been a lot of discussion of how to build variant types lately. -Dave