Skip to Content
Author's profile photo Former Member

Xcode and Swift for PowerBuilder developers: Part 2

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.

Screen Shot 2015-08-27 at 12.00.29 PM.png

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:

Screen Shot 2015-08-27 at 12.24.06 PM.png

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…

Screen Shot 2015-08-27 at 12.24.29 PM.png

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


  • 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 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.


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


statement block


  • 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 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


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.


I think that’s enough for now.  Loop statements (For and While) deserve their own chapter, and that’s up next…


Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      One correction:

      The PowerBuilder keyword that ends an IF...THEN block is "END IF" (with a space), not "ENDIF" (no space).

      -Paul Horan-