[pka]

So instead of writing herp.getOrElse(Darpity) you'd write getOrElse(herp, Darpity)

Polymorphism doesn't need to be tied to the first argument's type, it can depend on any number of properties of any number of arguments (see CL's and Clojure's multimethods).

[eli_gottlieb]

I'm not talking about polymorphism at all. I'm just talking about namespacing, name look-up for the method. Think of a world in which any number of classes might have a `getOrElse()` method, and they don't all do the same thing (so they're not just all methods of a single generic function). Now, how does the compiler know which one you're calling?

We could use some form of static overload resolution (like type-classes). However, it really does seem (to me) to be easier to just resolve the static overload based on the static type of the first argument, and then throw the rest of the overloading problems at dynamic dispatch.

When you think of a class as both a type and a module, it gets clearer. Many classes in the Scala collections library have a `map()` method. We could code `map()` as a single, universal generic function that dynamically dispatches on its first argument type... but nobody ever cared to override map as a virtual method anyway and that doesn't give us a consistent return-type at all. All we really want to say is that calling map over a `[a]` with a function `a -> b` returns a `[b]`.

[nessus42]

So, what you're saying is that we all of parametric polymorphism, ad hoc polymorphism, and subtype polymorphism, right?

You'll get no argument from me, but that doesn't mean that there should be an unfortunate syntactic distinction between the three.

[nessus42]

The above should read, "So, what you're saying is that we need all of [...]".

Sorry about that!

[eli_gottlieb]

I'm saying, what happens if more than one module provides a getOrElse() method?

In "classical" OOP, the type of the "dotted" parameter, the this pointer, the method receiver, tells the compiler to look in its own module/namespace for the method name.

If we just write getOrElse(herp,Darpity), then we now have to either make getOrElse a type-class method (type-classes are equivalent to certain usages of modules) to recover the same functionality of looking up the appropriate method, or we have to write herpModule::getOrElse(herp,Darpity).

[nessus42]

As I understand it, in statically typed languages that support multi-methods, you import the generic function declaration for a multi-method. This multi-method can be defined in zillion different modules. You only have to import the generic function declaration, not any of the function definitions. The generic function declaration can be parameterized, just like parameterized declarations in Scala. Single or multiple dispatch may be used to locate a method definition.

So, yes, your code does need more import statements. I don't consider this to be a problem. Your code, however, does not need to qualify the functions that it calls with the module where the function is defined.

[eli_gottlieb]

You would have to qualify the call with the module where the generic function is defined. Otherwise, you could import two modules that both define a generic function named foo() -- but whose foo() functions do completely different things.

[nessus42]

Yes. I consider this a feature, not a bug.