Discussion on: Juniors Literally Can't Write Switch Statements: What Senior PHP Developers Need to Focus On

View post

Replies for: DIGRESSION/SLIGHTLY OT, FEEL FREE TO DISREGARD As a Senior Developer, I hate switch functions. (Especially if they don't auto-break.) They were a...

They can be quite useful traversing through possible enum values. It kinda depends how the language implements switch functions. I program a lot in Kotlin and I like how they have implemented it (no need to break and you can use mutliple possible values which means no falling through kotlinlang.org/docs/reference/cont...)

Jon Bristow • Sep 28 '17 • Edited

Right, but only for simple things.

To me, especially with an OO design, I'd rather encourage:

// assume a calculator that only handles binary operators

Operator operator = Operator.parse("+"); //throws OperatorParsingException
operator.resolve(a, b);

Over

switch (operatorInput) {
  "+": add(a, b);
       break;
  "-": minus(a, b);
       break;
  default:
    throw OperatorParsingException(operatorInput);
}

Now, when we get back into functional, I'm not as confident in my design, but I think I would do it like this. (But the switch statement badness is not precisely involved anyway, I'm just thinking out loud here.)

(defmulti operator (fn [op a b] op))
(defmethod operator :plus [_ a b] (+ a b))
(defmethod operator :minus [_ a b] (- a b))

(operator :plus 5 6) ; =11

Wouter Doeland • Sep 29 '17 • Edited

Sure, but in the Operator#resolve function you will still need either an if or a switch statement. How I would do this in Kotlin:

fun resolve(a: Int, b: Int) = when(type) { // type is the operator type
        OperatorType.minus -> a - b
        OperatorType.plus -> a + b
    }

or:

fun resolve(a: Int, b: Int) =
    if(type == OperatorType.minus)
        a - b
    else if(type == OperatorType.plus)
        a + b
    else
        throw Exception("!?")

I think the first one is way more clear.