3 ms·
Languages shouldn’t try so hard to wrap syntax around one particular use for something, because you end up tearing the whole thing apart in maintenance. It’s s
by makecheck 9y ago
Languages shouldn’t try so hard to wrap syntax around one particular use for something, because you end up tearing the whole thing apart in maintenance. It’s sort of optimizing the writing of the code, which isn’t the worst part.
Here, “int result = switch...” seems nice for that one situation, “until it isn’t” (and in my experience these “until” events can come as soon as the very next time you have to maintain the thing). Oh, wait: I actually want to log something in one of the cases in addition to the assignment but since the entire thing is a fancy assignment expression now I have to rewrite 90% of it to add a glorified print statement for one of them!?
And it’s not just Java. In “new” C++ for instance, the highly-specialized syntax for loop iteration is nice but it has the same problem: sometimes the change you’re making does need iterators, unusual increment points, etc. and you end up peeling apart everything that was supposed to be so helpful and rewriting way more than you should need to.
- TomMarius 9y agoI don't get you. You can still use the old syntax without the arrow and add your print before you break with a value inside a switch expr.
- dragosiulian 9y agoYou probably missed the part below the first paragraph. You can have additional statements in case branches.
- dtech 9y agoYou're completely missing the point. The switch expression is exactly that, an expression. It can be used wherever you can use an expression. This is fundamental to programming languages and especially in functional programming languages where it is a requirement of everything in the language. You can use logging/side effect in it. You can not assign it to a variable, all valid in Java. Consider the if expression (ternary ?: operator in Java). In most modern languages (e.g. Scala, Kotlin, Rust) there is no ternary operator, and only an if-expression: int value = if(something) 1 else 2 According to you, this is wrong, but it isn't, you can still use it as a statement: if(something) { doThis() } else { doThat() } Just like you can have a statement (line) with just "1+1" or "doThis()", you can have a statement of just an if-expression. And you can also add side-effect (logging) withing expressions: int value = if(something) { log("Uh oh"); -1 } else { 1 } Making a language construct an expression is the complete opposite of tying it to a particular use-case, it's giving it the ultimate flexibility because you can use expressions everywhere.
- makecheck 9y agoI’m not debating why expressions are part of languages. I’m saying that I shouldn’t have to tear apart half the code just to make a change. And there are very simple examples of that problem, right in the article: 1. Allowing the entire switch expression to bind to the same assignment makes it difficult to maintain when adding a case that will not perform that assignment. Now, instead of adding one line, you’re tearing apart half the block and trying to find a way to make equivalent new code. 2. Even adding a single line to a case may be impossible without rewriting the case. Given some 'case "Bar" -> 2;', the maintainer has to redo the entire thing: rewrite it as 'case "Bar":' with a colon, add 'break 2;' to preserve original behavior, and then add their stuff. That’s just broken; it won’t even produce a clean "diff" because you’re “changing” lines that don’t have anything to do with your new code. And you can bet at some point that somebody may just plain forget to add back the "break" when rewriting the expression needlessly, introducing a bug.
- petters 9y agoI don't agree. Language designers are optimizing common use cases and that is a good thing.