David Abrahams <dave@boost-consulting.com>: > I think it's unnatural to try to tie MULTImethod implementations to a > single class. I'm not sure what you mean by that. What I was talking about wouldn't be tied to a single class. Any given method implementation would have to reside in some class, but the dispatch mechanism would be symmetrical with respect to all its arguments. > When you try to generalize that arrangement to two arguments, you > end up with something like the __add__/__radd__ system, and > generalizing it to three arguments is next to impossible. But it's exactly the same problem as implementing a generic function dispatch mechanism. If you can solve one, you can solve the other. I'm talking about replacing f(a, b, c) where f is a generic function, with (a, b, c).f (not necessarily that syntax, but that's more or less what it would mean.) The dispatch mechanism -- whatever it is -- is the same, but the generic function entity itself doesn't exist. > Where to supply multimethods that work for types defined in > different modules/packages is an open question, but it's a question > that applies to both the class-scope and module-scope approaches The class-scope approach would be saying effectively that you're not allowed to have a method that doesn't belong in any class -- you have to pick a class and put it there. That doesn't solve the problem, I know, but at least it would be explicit about not solving it! 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