I got the idea from dynamic dispatch in general having a performance cost. Of course, if you need runtime dispatch, having it built into the language is not any slower than hand-coding it, so in that sense it's convenient. But it's something to avoid in parts of code that are performance-critical, which seems like something Julia would be used for.

P.s.: I'm talking about dynamic multiple dispatch. I can't tell from the example if that's dynamic dispatch, all the information is available at compile-time. It's also not really 'multi'.

M Which to me reeks of double-talk and philisophical hoodoo-voodoo -- seriously, the LANGUAGE of that sets off warning bells in my head.

Since I don't see what makes it "dynamic" or how the WORD is even relevant to it, or again where in a compiled or pre-parsed language it would introduce a performance cost. In particular the use of the word "dispatch" makes it sound more like some sort of multithreaded thing, WHICH IT CLEARLY IS NOT.

It just reeks of the type of conceptual, professional educator / professional lecturer marketspeak nonsense that has NOTHING to do with how any of it actually works.

Maybe it's that I learned assembly first then pascal decades ago (in that order), but it's a CALL, not a "dispatch". The ADDRESS of the call determined at compile/parse time based on type UNLESS you're working with loose typecasting -- in which case the WORST you should have is a simple series of compare by type. NOT the end of the world.

Though again, this is someplace where strict typecast languages don't even HAVE this discussion. Which oddly is why my BS alarm is going off so hard over it, is so many of the sites trying to explain "dynamic dispatch" and "multiple dispatch" not only sound like someone's talking out their backside, but they also seem to mention languages like C++ where there is no reason for ANY of this terminology to even be relevant or applicable!

Again, in a compiled language with strict typecasting it's just a call... with loose typecasting it's a simple set of cmp/je back-to-back-to-back by the loose variable's object's "type" parameter. (which if they have ANY sense will be a integer, not the huffing name). Or even more efficient, have the parser build a table of pointers and use the type as an offset. SHL and BX are your friend. Just fill the table where there is no corresponding compatible type with pointers to a RETF... or better still the runtime error handler.

But to be fair, I tend to look at this stuff in a radically different fashion from what's hot and trendy with all the sick buzzwords right now.

I'm not sure if they're popular terms, but both "dynamic dispatch" and "multiple dispatch" are at least standardized enough to have Wikipedia articles of 1000+ words each. It's not hot and trendy (Lisp was mentioned).

You have done low-level stuff so perhaps you're familiar with vtables, which is just the typical implementation of (single) dynamic dispatch. Given your assembly knowledge, you can probably imagine how to extend it to multiple types. So maybe for you it doesn't need a fancy name, but the rest of us don't know assembly, so we rather use "multiple dispatch" than talk about pointers and jump tables.

The term is relevant to C++. Virtual methods are dispatched (or "called" if you prefer) dynamically: if you call animal.move() then you will call a different move for dogs than for cats. Which one gets called is (sometimes) determined at runtime.

Let's name them "calls with multiple jumps based on object type" if that helps. Julia, apparently, has calls with multiple jumps based on object type.