From: David Abrahams <dave@boost-consulting.com> > > [T3==T2 case corresponds to the above > > > > A.meth = foo > > I hope you are covering this case just for generality's sake. It's easy > enough to forbid. Yes, but Python is a dynamic language, you should allow for redefinition in some way. > > the idea is to allow optionally to specify together > > with an argument a supertype of the argument and to have > > the dispatching mechanism use the supertype instead > > of the type of the argument for dispatching: > > > > gf(a,b,_redispatch=(None,SuperTypeOf_b)) > > > > the dispatch mechanism will consider the > > tuple (type(a),SuperTypeOf_b) instead > > of (type(a),type(b)) for dispatching. > > More "sugarily:" > > gf(a, dispatch_as(b, SuperTypeOf_b)) > > Interesting. Not sure how I feel about this. > > > This is the moral equivalent of > > single dispatching: > > > > SuperTypeOf_b.meth(b) > > > > or super(SuperTypeOf_b).meth(b) > > Hmm. OK, I see the analogy. I hardly ever have to do that even in the > single case, but I get what you're up to. more than as a super, it can be useful if you are picky about ambiguities. > > you get the same effect as multidispatching > > simulated through chained single dispatching. > > That seems a bit arbitrary, but I guess there are other precedents in > Python for an arbitrary ordering (e.g. ordering on type names for > heterogeneous object comparison). Yes, e.g. the mro used for single dispatch in case of multiple inheritance. The other option is to totally refuse ambiguity. Which is also reasonable. Honestly there is no big agreement about whether automatically solving ambiguities is a good thing in general (even for the single dispatch case). See for a short opinionated survey: The Cecil Language Specification and Rationale Craig Chambers 2.7 Method lookup 2.7.1 Philosophy http://www.cs.washington.edu/research/projects/cecil/www/Refman/wmwork/www/ceci l-spec_12.html#HEADING38 The predictability depends not only on the rule but also on the complexities of the class hierarchies at hand, especially in the presence of multiple inheritance. For the stuff I tried with my multimethods impl, it seemed that the CLOS rule made sense, and getting ambiguities seemed more an impediment. As I said it corresponds to chained single dispatch and that was basically what I needed in sweeter way. Anyway this can be made configurable for the single gf. regards.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4