> > [Alex] > >> I'm saying that if, by mistake, the programmer has NOT > >> registered the A->C adapter (which would be easily coded and work > >> perfectly), then thanks to transitivity, instead of a clear and simple > >> error message leading to immediate diagnosis of the error, they'll get > >> a subtle unnecessary degradation of information and resulting > >> reduction > >> in information quality.
[Guido] > > I understand, but I would think that there are just as many examples > > of cases where having to register a trivial A->C adapter is much more > > of a pain than it's worth; especially if there are a number of A->B > > pairs and a number of B->C pairs, the number of additional A->C pairs > > needed could be bewildering. [Alex] > Hm? I meant if there were multiple A's. For every Ai that has an Ai->B you would also have to register a trivial Ai->C. And if there were multiple C's (B->C1, B->C2, ...) then the number of extra adaptors to register would be the number of A's *times* the number of C's, in addition to the sum of those numbers for the "atomic" adaptors (Ai->B, B->Cj). > > But I would like to see some input from people with C++ experience. > > Here I am, at your service. [...] > It's in the running for the coveted "Alex's worst nightmare" prize, Aha. This explains why you feel so strongly about it. But now, since I am still in favor of automatic "combined" adaptation *as a last resort*, I ask you to consider that Python is not C++, and that perhaps we can make the experience in Python better than it was in C++. Perhaps allowing more control over when automatic adaptation is acceptable? For example, inteface B (or perhaps this should be a property of the adapter for B->C?) might be marked so as to allow or disallow its consideration when looking for multi-step adaptations. We could even make the default "don't consider", so only people who have to deal with the multiple A's and/or multiple C's all adaptable via the same B could save themselves some typing by turning it on. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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