Yes, but the
if() ... elseif() construct is more flexible because it allows you to compare different values.
For instance, in a classic language with a CASE construct, you'd have something like this:
CASE MyVariable of
1: @DoOneThing()
2: @DoAnotherThing()
3,4,5: @DoYetAnotherThing()
else
@DoDefault()
ENDCASE
But
MyVariable can only be - in this instance - a numeric value.
With an
if()...elseif() construct, you can mix and match data types:
IF((MyVariable=1) and (MyOtherBooleanVariable))
@DoOneThing()
ELSEIF((MyVariable=2) and (MyStringVariable="INVOICE"))
@DoAnotherThing()
ELSEIF((MyVariable>2) and (MyVariable<=5) and @MyCustomFunction())
@DoYetAnotherThing()
ELSE
@DoDefault
ENDIF
A case - no pun intended - could be made that the
case structure is more efficient since only one of the expressions is evaluated, whereas an
if()...elseif() construct evaluates all conditions until it finds the proper match, thereby resulting in better performance, but I doubt that anyone could actually measure that performance increase in a real world scenario.
It should also be stated that PlanetPress Talk is a function-based language: each statement (and indeed, each operator) is actually a function call. So if we were to implement a case statement, it would likely look like this:
switchcase(&MyVariable)
case([1], @DoOneThing())
case([2], @DoAnotherThing())
case([3,4,5], @DoYetAnotherThing())
caseelse(DoDefault)
endswitchcase
We'd have to use an array as the first parameter because PlanetPress Talk functions do not accept a variable number of parameters (well... at least not as its first arguments). Not to mention that we'd have to find a way for the function to accept arrays of different data types, something that's not natively possible for function calls in PlanetPress Talk
And in the end, if you ask me, that syntax is not much leaner than the current
if()...elseif() one. Unfortunately, we're a bit limited in the types of implementations we can add to the language.
Previous Topic
Index