Code Structures
This installment of the series will look exclusively at the structure and format of the code within Swift and PowerScript. We'll talk about the basic differences in the way code is organized in Swift vs. PowerBuilder, and we'll look at specific examples of code blocks, IF/THEN/ELSE statements, and CASE vs. SWITCH statements. Part 1 can be found here.
Here's a typical (although rather boring) block of Swift code, shown in an Xcode playground.
Even if this is the first Swift example you've ever seen, there are some basic assumptions that you can make. It uses curly braces to surround blocks of code, the keywords are in lowercase, function definitions have arguments and return values... It's just the details of the syntax that are different from PowerScript.
One basic difference is the basic structure of the way the IDE works with the code files. Imagine this same code as a PowerBuilder NVO class, and that this represents code in the constructor event. or within some other public method definition. You wouldn't see the function definition for prepareGreeting() "nested" inside that event/method script, because the PowerBuilder IDE hides that structure from you. In this event's code, you'd only have lines 3, 4, 5, and 21. The function prepareGreeting() would be coded in a separate editor window, which you'd select from the function list dropdown.
Here's a screen shot of that same code as a PowerBuilder NVO. First, the constructor event script:
Now, the function definition for the prepareGreeting method. To get there, I go to the Function List tab at the bottom, and pick the prepareGreeting() method from the list of functions. You never see two function or event definitions in the same editor window. Working in Swift and Xcode is like editing PowerBuilder code in "Edit Source" mode all the time. Some people will like that, and some will hate it, but that's what it is...
Variable Scoping and Code Blocks
Look at the example Swift code in figure 1 again. Note that there are two separate sets of variable declarations - the first three on lines 3, 4, & 5 occur "outside" of any specific code block, while the declaration for the variable "prefix" is inside the code block for the function prepareGreeting(). That's not just for readability - it affects the scoping of the variables as well.
The three variables in the "outer" code section will be visible to any function defined within the entire Swift file. If there was another function declaration below the last curly brace in the prepareGreeting() code block, that function would have access to those three variables as well. There's one copy of those for all defined methods within the file.
The variable "prefix" is defined inside the curly braces that make up the function body for prepareGreeting(). That variable will only exist in the context of that function. I can't reference "prefix" from outside that code block. If there were another function declaration elsewhere in the file, it could have it's own variable named "prefix", and there wouldn't be any conflict with the one defined inside prepareGreeting().
To compare that to PowerBuilder, think of them as "instance" vs. "local" variables. The three variables on lines 3, 4, and 5 would be analogous to private or protected instance variables in a PB class. All method and event scripts in the class would be able to reference them. The variable "prefix" can be compared to a local variable, whose scope is only the code block in which it is defined. You cannot reference the variable "prefix" from outside the code block in which it's defined - that gets a compiler error.
NOTE: Even though Swift and PowerBuilder both allow you to define local variables whose names match existing instance variables, it's generally not a good practice... The local copy of the variable would take precedence during the execution of the code block, and would not affect the value in the instance variable.
IF / THEN / ELSE statements
PowerBuilder
- PB does not require parentheses around the IF condition, but it can be a good practice at times.
- PB requires the THEN keyword (even if there's no ELSE block).
- PB requires an ENDIF keyword to terminate the entire IF statement block
- PB supports the use of the ELSEIF keyword.
- There are no statement separators or designations of code blocks assigned to any of the clauses
Swift
- Swift does not require parentheses around the IF condition either.
- Swift does not use the THEN keyword. The code block following the IF condition represents the THEN block of code.
- Swift does not support an ELSEIF keyword. If that's the structure that's needed, just code another IF statement following the ELSE keyword.
- Swift does not require an ENDIF keyword. It's all about the code blocks and curly braces.
CHOOSE CASE vs. SWITCH statements
Rather than construct long, convoluted IF/THEN/ELSE/ENDIF statements, both languages support the concept of a CASE statement, where the individual conditions and resulting code blocks are listed in order. The first condition that evaluates to TRUE is executed, and the rest are skipped.
PowerBuilder
PB uses the CHOOSE CASE statement, and the syntax is pretty straightforward. Note: this is not the case() datawindow expression function...
CHOOSE CASE testexpression
CASE expressionlist
statement block
CASE expressionlist
statement block
CASE ELSE
statement block
END CHOOSE
- testexpression must evaluate to a single value
- expressionlist can be a single value, a list of comma-separated values, a range separated with "TO" ( 1 TO 10 ), or a boolean expression using the keyword IS ( IS > 5 )
- There can be any number of CASE blocks. The first one to be satisfied will execute its statement block, and then drop out.
- The CASE ELSE block is not required, but must be at the end of the list when used.
- The set of values represented by all the CASEs do not have to be exhaustive - there's no compiler error if you don't address all possible values.
Swift
Swift uses the SWITCH statement. There are several variants, but the basic format is very similar in structure to its PB equivalent.
switch testexpression {
case expressionlist:
statement block
case expressionlist:
statement block
default:
statement block
}
- testexpression (in this form of the statement) must evaluate to a single value. (We'll discuss tuples in a later installment...)
- Curly braces at the start and the end of the list of CASE clauses
- The individual statement blocks do NOT require curly braces around them. You can add them for readability, but they're not required.
- The list of CASEs must be exhaustive - all possible values for testexpression must be addressed. It's a compiler error if you don't...
- The default: keyword is just like "Case Else" in PB. It's the final entry in the list, and is the catch-all for any value not specifically addressed.
- The expressionlist can be a single value, a list of comma-separated values, or a range of values. There are two versions of the range operator.
- Three dots (...) indicate an inclusive range. 1...10 will be true for values 1 through 10.
- Two dots and a greater-than sign (..>) indicate a "half-open" range. 1..>10 will be true for values 1 through 9.
Conclusion
I think that's enough for now. Loop statements (For and While) deserve their own chapter, and that's up next...
-Paul-
- SAP Managed Tags:
1 Comment
