Using ‘switch’ to match arbitrary logic instead of string or number literals

EDIT: Oops, chalk this up as another case of reinventing the wheel. We already have all this in the form of the ?: ternary operator, as masklinn pointed out:

https://news.ycombinator.com/item?id=20736714

----

Inspired by this, I cooked up a crude imitation in (ugly/functional'ish?) Swift:

    let result = [(firstCheck,  1),
                  (secondCheck, 2),
                  (thirdCheck,  3)]
                  .first { $0.0() }?.1

That iterates over an array of (() - > Bool, Value) tuples and returns the second element of the first tuple whose first element is a function that returns true, otherwise nil. The types of all values must be the same. Could shorten .first to .firstTrue or something.

And a version that's closer to your idea:

    typealias BooleanFunction = () -> Bool
    typealias FunctionValuePair<ResultType> = (BooleanFunction, result: ResultType)

    func pickOne<ResultType> (_ pairs: FunctionValuePair<ResultType>...) -> ResultType? {
        pairs.first { function, result in
            function() == true
        }?.result
    }

    let result = pickOne(
        (firstCheck,  "one"),
        (secondCheck, "two"),
        (thirdCheck,  "three"))
        ?? "default"

You could make the default result an argument for pickOne so that it never returns nil, but I prefer to keep it an optional.

Though it's too early in my day to think of better names. :)

Maybe something like a hash table/array could be used, predefined with the key being the URL and the value being the config, then the function could do something like return the value from the array given the key, with some kind of logic to return the unknown config by default if the key wasn't in the array (this would all depend on the language - it could be that such a method might be worse for readability; it would also depend on if the array could be defined elsewhere as an included file/module or something, etc).

This style of writing switch statements as long sequences of if-elseif-else makes it very easy to mess up when you add additional clauses. It also does nothing to guarantee the conditions are mutually exclusive, which would make the comparisons order-dependent. Last but not least I would guess the compiler does not have as many options to optimize this kind of code, compared to switch statements (a switch statement can be compiled to either chained jumps, or a jump table, but the if-elseif-else implies there could be order-dependencies and/or side-effects evaluating the conditions), limiting the compiler.

This is all reasoning from the perspective of a compiled language of course. But even in Javascript implementing switch-statements as if-elseif-else seems like an anti-pattern to me.

>> Switch statements are a more like goto, and are more low level.

I know about 'goto considered harmful', but sometimes a simple jump table is just what you need, no need to come up with 'better' ways ;-)

As others have said, this pattern is used for pattern matching when the language doesn't have specific constructs for it.

When I use it, I will extract it into a separate function, and just return the needed condition. That way you don't need to worry about case fall through.

    function getCondition(param) {
        switch (true) {
            case ConditionOne(param): return 'condition one'
            case ConditionTwo(param): return 'condition two'
            case ConditionThree(param): return 'condition three'
        }
    }

They sure are. I often extract logic into a function just so I can use early returns and have less local state.

I mean, they're a recipe for disaster in C++, but I don't code much C++ anymore. In JS and similar-enough languages it's lovely.

And you just introduced a bug.

You refactored the code and changed the logic without noticing.

The same is in JavaScript:

  return (twitterUrl && config.twitter) || (githubUrl && config.github) || default

Very true, then somebody else ends up maintaining the code and gets a ticket to add this feature and chaos plays out.

One thing I learned early on - true and false vary across platforms. Hence I learned to define true and false at the start of the code with realTrue=(1=1) and realFalse=(1=0). As some systems have 1 or any positive value as true, some have -1 as true. It can get messy, bit like endians (big or little) the same holds true for true and false.

And a bunch of `if` statements could get hard to maintain once it turns into a bunch of related compound statements, while it doesn't check for missing combinations compile-time.

But I don't think you should call any function outside of constructors with more than three-ish parameters to begin with, so probably you would get a dictionary or list of URL's by the time it grows out of control.

ahhhh ok, then I've misunderstood the code, thank you. Disregard :)

Not true. Go uses logic expressions in the case statements all the time. And as pointed out above, a switch defaults to checking against true.

https://tour.golang.org/flowcontrol/11

In fact, the compiler building a static switch table from non-constant expressions sounds a little bit impossible ;-)

The guy also liked Microsoft's ecosystem (despite coding for a Linux backend) and drove a Chinese-made SUV. I'm comfortable writing off the `switch` pattern as another one of his idiosyncrasies. It also annoyed everyone who came across his code, just as his political views irked people outside of keyboard-mashing time.