From: "Greg Ewing" <greg@cosc.canterbury.ac.nz>
> 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,
"reside in" is approximately equivalent to what I meant by "tied to". I
think it's unnatural to force users to associate a function designed to be
considered symmetrically over a combination of types (and "type
categories", I hope) with a single one of those types.
That approach also prevents another important use-case:
I want to use type X with generic function F, and can write a plausible
implementation of some multimethod call used by F for X, but the author of
X didn't supply it
> > 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.
Are you talking about allowing the "self" argument of a multimethod to
appear in any position in the argument list? Othewise you get a
proliferation of __add__, __radd__, __r2add__, etc. methods
> > 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!
And that's progress?
Anyway, you've managed to avoid the most important problem with this
approach (and this is a way of rephrasing my analogy to the problems with
Koenig lookup in C++): it breaks namespaces. When a module author defines a
generic function he shouldn't be forced to go to some name distribution
authority to find a unique name: some_module.some_function should be enough
to ensure uniqueness. 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)
within the class body, I guess it's OK with me, but it seems rather
pointless to force the association with a class in that case, since the
really important association is with the module defining the generic
function's semantics. Explicit is better than implicit.
-----------------------------------------------------------
David Abrahams * Boost Consulting
dave@boost-consulting.com * http://www.boost-consulting.com
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