Writing Extensions

[Mark Wieder]

On 05/24/2017 03:25 AM, Mark Waddingham via use-livecode wrote:

> The use-case which causes subtle bugs and errors is where one case 
> requires a 'bit more code' before the others (where code, fallthrough, 
> code is *not* erroneous but intended) - also it is a rarely used pattern 
> in C (because it is difficult to maintain).

I hesitate to get into religious wars here (especially with you, because 
there's no way I'd end up on top <g>) but...

I use switch statements all the time. All the time. I utilize the 
fallthrough mechanism where it's useful to avoid repeating code and I've 
just gotten into the habit of writing a break statement immediately 
after writing a case statement, so I (mostly) keep out of trouble that way.

That said, the "problem" with switch statements is exactly what you have 
laid out, user errors with forgetting the break statement.

> 
> Taking this into account, then perhaps a better solution would be 
> ('choose' used here for the sake of argument):
> 
>    choose tValue
>      when 1
>      when 2
>      when 3
>        -- executes if tValue is 1, 2 or 3
>        -- never falls through
> 
>      when 4
>        -- never falls through
> 
>      default
>    end choose
> 
> This caters for both cases (1) and (2) and is unambiguous.


ruby implements almost exactly this syntax ("case" instead of "choose", 
but otherwise):

case x
     when "a", "b"
         puts "a or b"
     when "c"
         puts "just c"
     else
         puts "something else"
end

while python doesn't have a switch construct as such, dictionaries 
neatly provide the same functionality in a possibly more readable and 
maintainable form (here as a function):

def f(x):
     return {
         'a': 1,
         'b': 2,
     }[x]

 > As I said before, the lack of switch in LCB isn't because we don't want
 > a construct like that; just that we'd like one which doesn't have the
 > issues of C-style switch. (The best way to avoid people accidentally
 > introducing subtle bugs, is to ensure the language is designed to not
 > let them do so!)

It's *always* possible to introduce bugs, subtle or not. The best way to 
avoid that is not to allow people to code <g>. The idea of a "continue" 
statement to force a fallthrough is intriguing, although I can't get the 
unwanted images of Cobol out of my mind. I do like the idea of having 
the language guide users to preventing errors, and possibly the ruby 
syntax with the continue statement might be the best way forward. In 
that case (heh...) I'd also like the syntax to allow for

case x
     when someFunctionThatReturnsAorB()
         puts "a or b"
     else
         puts "something else"
end

-- 
  Mark Wieder
  ahsoftware at gmail.com