[Python-Dev] *Simpler* string substitutions

David Abrahams David Abrahams" <david.abrahams@rcn.com
Fri, 21 Jun 2002 17:39:29 -0400


From: "Alex Martelli" <aleax@aleax.it>


> 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
think
> > 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.
> """

Oh, sorry I missed that.

> 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
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_traits<libA::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