Swift for PowerBuilder Developers – Part II


This is the second of a series of posts that introduce the Swift programming language and the Xcode IDE to PowerBuilder developers.  Part 1 can be found here: Swift for PowerBuilder Developers: Part 1

In this installment, 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.


Code Structures

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.  This might represent 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 code 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 its 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


  • Swift does not require parentheses around the IF condition.
  • 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.


  • 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 to string together consecutive logical branches.
  • There are no statement separators or designations of code blocks assigned to any of the clauses


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 around the entire set 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…



About Paul Horan

Software Technology - lots of experience with Sybase and IBM mobility/cloud offerings.
This entry was posted in Software, Swift and tagged , , , . Bookmark the permalink.

1 Response to Swift for PowerBuilder Developers – Part II

  1. Pingback: Swift for PowerBuilder Developers – Part III | Paul Horan

Comments are closed.