Why no multiple-dispatch?

Aerolite via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sun Aug 24 19:04:43 PDT 2014


On Monday, 25 August 2014 at 01:34:14 UTC, Idan Arye wrote:
> On Monday, 25 August 2014 at 01:10:32 UTC, Aerolite wrote:
>> -- No syntax modification (unless you want the feature to be
>> optional)
>
> If this ever gets into the core language, it absolutely must be 
> optional! Think of the implications of having this as the 
> default and only behavior:
>
>  * Every overloaded function will have to do a runtime 
> typecheck - this not only causes a usually unnecessary overhead 
> but also has a negative impact on branch prediction.

Well, you'd only have to resolve *class* parameters (since
obviously literals and structs don't support inheritance). My
brain is a little foggy at the moment due to this nice flu I
have, but do we even need to do this at run-time? It's not like
we can do a Java and use run-time reflection to create new class
instances. The closest thing we have to that is Object.factory,
but that's all compile-time built and type-safe as far as I'm
aware? Or am I being silly?

>  * No way to reuse the overload that accepts an object of the 
> parent class inside the implementation of the overload that 
> accepts an object of the child class.

Ok, yep, I didn't consider this. Fair point. But surely an
attribute such as @nomulti could prevent this problem? Admittedly
though, given this problem, the scale of potential breaking
changes would necessitate the opposite - an @multimethod
attribute, for instance (much like you suggested in your earlier
reply).

Clojure, it seems[1], explicitly denotes multimethods (with
defmulti), so it seems as though an @multimethod might be the way
to go.

>  * What if you have multiple overloads that happen to be 
> templated? Now the compiler will have to instantiate them all!

Hard to say, although surely there could be some examination of
what is and is not necessary to instantiate. This is again making
the implementation a tad more complicated, though. That said, if
something like @multimethod existed, it would assist in this
matter.

> Anyways, I don't think you get just how strong this language's 
> tendency to push features to the library is, so I'd like to 
> point you to this post by the language's creator:
>
> http://forum.dlang.org/thread/lt00a9$2uoe$1@digitalmars.com#post-lt00a9:242uoe:241:40digitalmars.com

Heh. Well, that's Walter for you! :P But I definitely understand
the push towards the library. I just feel that handling method
dispatch, even in compile-time template code, is not something
that we should really be writing ourselves. It's like trying to
do virtual method calls in C!

   [1]:
http://clojure.org/multimethods


More information about the Digitalmars-d-learn mailing list