5 ms·

How do they get so confused about it? Is it because Java also allows overloading, which is a sort of static multiple dispatch?

twoodfin 11y ago
Exactly: foo.bar() has dynamic behavior based on the runtime type of foo. Why shouldn't foo.bar(baz) similarly be able to distinguish the runtime type of baz and pick the 'right' overload? Would it be more surprising to Java newbies if it did work that way?
- kazinator 11y ago
  But then, what is the point of foo being associated with the class of bar? Multiple dispatch screams for the abolishment of methods as properties of objects, in favor of generic functions. Youc an still have the syntactic sugar obj.foo(arg), but it basically just translates to foo(obj, arg) where foo is a generic function not associated with foo's class in any way, and obj and arg have equal status. This generic function is what has methods.
- kazinator 11y ago
  But then, what is the point of foo being associated with the class of bar? Multiple dispatch screams for the abolishment of methods as properties of objects, in favor of generic functions. Youc an still have the syntactic sugar obj.foo(arg), but it basically just translates to foo(obj, arg) where foo is a generic function not associated with foo's class in any way, and obj and arg have equal status. This generic function is what has methods. Say we implemented "funky" numbers, and would like to implement multiplication of funky and real. When funky is the left argument we get funky.mult(real). If real is no the left, we get real.mult(funky). These functions do the same thing (the multiplication is commutative), yet ... they have to live in separate classes? It is nonsensical. Under generic functions, we just have mult(real, funky) and mult(funky, real) which are methods of the generic mult(whatever, whatever). They both belong to the one generic function: that is the more reasonable organization.
  - andrioni 11y ago
    That's the way Julia does multiple dispatch, and it works well.
  - StefanKarpinski 11y ago
    > But then, what is the point of foo being associated with the class of bar? One benefit is that the name `bar` is looked up in `foo`'s namespace, which means that it doesn't have to be in the current global namespace. This is a mixed blessing, but it's sometimes what you want.
    - kazinator 10y ago
      That's an interesting point and basically leads us to "member generic functions". An object has some static slot which is a function, and treated as a method: it can be called obj.meth(args, ...). But, this method is also a generic function. A generic function is a function; an object can have a function, and so an object can have a generic function.
    - wtbob 10y ago
      You're quite right, but does it make sense to conflate objects and namespaces that way? Might it not make more sense to separate the concerns?
      - akavi 10y ago
        It might, but it also might be more typing/visual noise for little benefit.
      - kazinator 10y ago
        Object must have name spaces by definition, because they are collections of named properties. These name spaces do not have to be conflated with program lexical scopes, whereby if you are a piece of code such and such a "blessed" function, you "see" the name space of the class as if it were lexical variable bindings. You definitely don't want crud like different scopes in the program which are all working with exactly the same object, and want to access slot S, but they all refer to a different S because they are associated with a different place in the inheritance hierarchy, and that hierarchy contains unrelated slots named S at different levels. A given object must just have one S.
kevincox 11y ago
That's probably a large component of the problem. It's not unreasonable to expect both methods and overloading to use runtime types. I think this comment sums it up well: https://news.ycombinator.com/item?id=11528588 https://news.ycombinator.com/item?id=11528588

twoodfin 11y ago

Exactly: foo.bar() has dynamic behavior based on the runtime type of foo. Why shouldn't foo.bar(baz) similarly be able to distinguish the runtime type of baz and pick the 'right' overload? Would it be more surprising to Java newbies if it did work that way?

kazinator 11y ago
But then, what is the point of foo being associated with the class of bar? Multiple dispatch screams for the abolishment of methods as properties of objects, in favor of generic functions. Youc an still have the syntactic sugar obj.foo(arg), but it basically just translates to foo(obj, arg) where foo is a generic function not associated with foo's class in any way, and obj and arg have equal status. This generic function is what has methods.
kazinator 11y ago
But then, what is the point of foo being associated with the class of bar? Multiple dispatch screams for the abolishment of methods as properties of objects, in favor of generic functions. Youc an still have the syntactic sugar obj.foo(arg), but it basically just translates to foo(obj, arg) where foo is a generic function not associated with foo's class in any way, and obj and arg have equal status. This generic function is what has methods. Say we implemented "funky" numbers, and would like to implement multiplication of funky and real. When funky is the left argument we get funky.mult(real). If real is no the left, we get real.mult(funky). These functions do the same thing (the multiplication is commutative), yet ... they have to live in separate classes? It is nonsensical. Under generic functions, we just have mult(real, funky) and mult(funky, real) which are methods of the generic mult(whatever, whatever). They both belong to the one generic function: that is the more reasonable organization.
- andrioni 11y ago
  That's the way Julia does multiple dispatch, and it works well.
- StefanKarpinski 11y ago
  > But then, what is the point of foo being associated with the class of bar? One benefit is that the name `bar` is looked up in `foo`'s namespace, which means that it doesn't have to be in the current global namespace. This is a mixed blessing, but it's sometimes what you want.
  - kazinator 10y ago
    That's an interesting point and basically leads us to "member generic functions". An object has some static slot which is a function, and treated as a method: it can be called obj.meth(args, ...). But, this method is also a generic function. A generic function is a function; an object can have a function, and so an object can have a generic function.
  - wtbob 10y ago
    You're quite right, but does it make sense to conflate objects and namespaces that way? Might it not make more sense to separate the concerns?
    - akavi 10y ago
      It might, but it also might be more typing/visual noise for little benefit.
    - kazinator 10y ago
      Object must have name spaces by definition, because they are collections of named properties. These name spaces do not have to be conflated with program lexical scopes, whereby if you are a piece of code such and such a "blessed" function, you "see" the name space of the class as if it were lexical variable bindings. You definitely don't want crud like different scopes in the program which are all working with exactly the same object, and want to access slot S, but they all refer to a different S because they are associated with a different place in the inheritance hierarchy, and that hierarchy contains unrelated slots named S at different levels. A given object must just have one S.

kevincox 11y ago

That's probably a large component of the problem. It's not unreasonable to expect both methods and overloading to use runtime types. I think this comment sums it up well: https://news.ycombinator.com/item?id=11528588 https://news.ycombinator.com/item?id=11528588