David Abrahams <dave@boost-consulting.com>: > I think it's unnatural to force users to associate a function > designed to be considered symmetrically over a combination of types > ... with a single one of those types. I agree, but the alternative seems to be for it to reside "out there" somewhere in an unknown location from the point of view of code which uses it. > Are you talking about allowing the "self" argument of a multimethod to > appear in any position in the argument list? Something like that. I haven't really thought it through very much. Maybe the method name could be systematically modified to indicate which argument position is "self", or something like that. > > That doesn't solve the problem, I know, but at least it > > would be explicit about not solving it! > > And that's progress? Maybe. I don't know. At least it would generalise and make available to the user what's already there in an ad-hoc way to deal with numeric types. > Class authors had better be able to say precisely > which module's idea of "some_function" they're implementing. If you want > class authors to write something like: > > def some_module.some_function(T1: x, T2: y) That would only be an issue if T1 and T2 were already both using the name some_function for incompatible purposes. That can happen now anyway with multiple inheritance -- name clashes can occur whenever you inherit from two pre-existing classes. I don't see that it's any more of a problem here. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
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