[kennywinker]

I've seen essentially this code in so many organically grown codebases (when they grew up without types). It's usually close the the UI, because someone had to quickly add an alternate path to support some new user interaction

    function find_user(person) {
        if user is string {
            query_by_name(person)
        } else {
            query_by_name(person.name)
        }
    }

and yeah, we all know it's kinda messy, but also that logic has to live somewhere and we need this feature asap so it passes code review. I wrote a test for it, ship it.

[sseagull]

I came very close to writing almost this exact code just the other day (except it was username or user id for me), but came to my senses. It's just so tempting in a dynamic language...

In a static language, you either can't do it, have to really go out of your way to do it, or at least do function overloading (which is a bit cleaner)

[fiddlerwoaroof]

Calling a function like this “ensureUser” is pretty idiomatic and useful, in lisp-style code bases. I think it’s a pattern related to “parse, don’t validate” in static-type lands: rather than _checking_ what the type is and throwing an error, you define a function that knows how to turn various representations of your type into its canonical shape.

[freemint]

Sounds like a brilliant case for multiple-dispatch.

[kennywinker]

Right so we have:

    function find_user(person: string)

and also:

    function find_user(person: Object)

how long before someone writes this:

    find_user(person: { name: "dave" })

meanwhile, someone else, not suspecting that they'll be handed a weird half-formed `User` object adds `person.id` somewhere in the body of the Object version of `find_user` and now we have a weird edge-case where very rarely `find_user` panics because the user object we're handed doesn't have an id??? Great, I just lost an hour trying to dig that out of the logs, and the users are starting to think of the product as flakey because the bug has been in prod for over a month before we finally believed them enough to look into it.

Just. Use. Types. Multiple dispatch won't save you on its own. You NEED compile-time types.

[david422]

Somebody downvoted you, I'm guessing because they think this is a silly example and have never actually seen something like this. I have, in a production code base.

[freemint]

Multiple dispatch and compile time times are not exclusive at all.

[kennywinker]

I'm saying the problem isn't solved by multiple dispatch alone, but it is solved by compile time types alone. You can use both together, of course.

[freemint]

The issue whether the language is interpreted or compildd (which would distinguish compile time types from strong types) is in my opinion completely orthogonal to the issue of how dispatch works. Strong types and multiple dispatch fix the issues I see even in an interpreted language.