Swift for PowerBuilder Developers – Part I


I’ve been a developer most of my career, and I’ve worked with a number of different programming languages.  I spent most of the 90’s and early 00’s working in PowerBuilder.  I still think it’s one of the cleanest, easiest to understand Object-Oriented programming environments available today.  (And, yes, it’s still available and has a bright future with Appeon.)

But with all of PowerBuilder’s strengths, it never really did mobile all that well, and it remains a proprietary Windows-only IDE to this day.  That rules it out for Mac or iOS development.  If you’re targeting those platforms, there’s really only one game in town, and it comes from Apple.  Their IDE is called Xcode, and (until recently), you programmed in a language called Objective-C.

In my opinion, Objective-C is just about the exact opposite of the PowerScript language.  It’s a variant of the C language (which I never used all that much), so I find it extremely difficult to read and even more challenging to learn.  But, if you wanted to write iOS apps, this was a hill you had to climb…

In 2014, Apple introduced the Swift programming language as a new option for development in Xcode, and it is a VAST improvement over Objective-C.  Simpler syntax rules, cleaner code structures, and much easier to read and understand.

So I thought I’d start a quick series of blog posts that compare and contrast Xcode and Swift with PowerBuilder and PowerScript.  There are still a great many PowerBuilder developers in the world (even more ex-PowerBuilder developers…), so I thought this would help a lot of people get going.  We’ll start with the basics, like variable and function declarations, and work our way up to the more complex topics like delegates, protocols, and closures.

Getting Started

Step 1 in working with Xcode and Swift is pretty straightforward:  get a Mac…  Xcode is not available on Windows or Linux.  You have to have a Mac, and you should be running the latest release of the OS/X operating system, El Capitan 10.11. Xcode is available for free from Apple, so you can get started writing code almost immediately.  However, if you plan on compiling your apps and actually deploying them to real devices (not emulators), you’ll need to sign up for an Apple Developer account, and that carries an annual subscription fee of $99.00 for an individual account.

PowerBuilder obviously requires a license from SAP (and soon, Appeon), but compiling and deploying applications has always been royalty-free.  PB apps don’t need to be digitally signed to be deployed onto other computers or devices, but Mac and iOS apps do.

Let’s start with some basics of the Swift language, and compare those to similar constructs in PowerScript.

Variable Declarations

Both Swift and PowerScript are considered “strongly-typed” languages, meaning that every variable must be of a specific type at design time.  When you write the line of code, you must give a variable a unique name and a defined type – either a standard datatype (Int, String, Double…), or a defined class or structure definition. For now, we’ll only be referring to “local” variables, even though both languages support the concept of instance, shared or class, and global variables.


A variable declaration in PowerScript looks like this:

{ constant } datatype { size } { precision } variablename { = value }

For example,

CONSTANT string l_myString = "some string"
  • Adding the optional keyword “constant” makes the variable read-only, and you MUST provide an initialization expression.  Any code that tries to alter the value of a variable defined as a CONSTANT will not even compile.
  • For most declarations, the datatype comes first.  This can be a standard system datatype, like “string” or “int” or “double”, or a known class or structure name.
  • size (optional) is for blob variable declarations, and denotes the max size of the blob in bytes.
  • precision (optional) is for decimals only, and denotes the number of places to the right of the decimal point.
  • variablename must be unique within the event or function script.
  • “= value” is an optional initialization value for the variable.  “value” must be of the same type as the declaration.


A variable declaration in Swift has a slightly different look, and is a lot more flexible, but most of the same concepts are there.

let | var variableName : type = expression

Notice the first choice you have to make – whether to use the keyword let or var.  One of these two keywords must be used.  If you want the variable to be read-only, use let.  If your code will change the value stored in the variable, use var.  So, let is Swift’s equivalent to PowerScript’s constant keyword, and var is just like the absence of the constant keyword – a normal mutable variable.

The variableName must also be unique within the .swift code file (which we’ll discuss in a future post, when we examine the structure of the code assets between the two environments).

A colon must be present to separate the variableName from its type.  You can read that colon as if it says “is of type”.

type can be any defined system type, class or structure definition, and the expression can be used to provide a default value during initialization.  But here’s a neat trick – if you provide an initialization expression, Swift will infer the datatype from it.  You can shorten the declaration and leave off the colon and the datatype.  For example,

let myVariable = "some string"

Swift will see that the initialization expression is a string, and will assign the String datatype to myVariable automatically.

Optional variables and null values


Here’s another difference between PowerScript and Swift.  In PowerScript, it’s perfectly fine to declare a variable and leave it uninitialized.  If it’s a standard datatype (int, string, double, etc…), PB will initialize the variable for you.  Numeric datatypes get set to 0, strings get set to the empty string, and dates contain ‘1900-01-01’.  That’s also true for all the individual fields defined within a structure class.  Non-Visual Object (or “NVO”) variables will be set to NULL until they’re instantiated with a CREATE statement.


Swift, on the other hand, requires that all variables be initialized to a non-null value before are they are used in the code.  Swift will not automatically initialize an integer variable to zero, or set a string variable to the empty string.  If your code references a variable that has not been initialized or specifically assigned a non-null value, you’ll get a compiler error.

But there are cases where a NULL value is the correct state of the variable!  For example, suppose you wrote an app that invoked a web service to retrieve the current temperature. If there’s no internet connection, the service can’t be called.  You don’t want to initialize the value of the variable to 0 degrees – that would indicate that it’s the dead of winter!  Data that’s “zero” and data that’s missing are two distinctly different states.

In this case, Swift has the concept of “optional” variables.  You have to decide, on a variable-by-variable basis, whether it needs to support the “uninitialized” state.  The syntax changes slightly for these too.  In the declaration, just add a question mark immediately after the datatype, as follows:

var temp : int?

The variable temp can now be referenced in the code without receiving a compiler error.  But there’s a twist…  Let’s say the variable temperature contained the value 85.  If you write a line of code that prints out the temperature like this:

print( "The temperature is currently \(temp) degrees.")

You’d expect to see “The temperature is currently 85 degrees” in the console.  However, what you’ll see is “The temperature is currently Optional(85) degrees”…   This is because the type of the variable temp is no longer an “int”, it’s an “optional int”.  To extract only the value and leave the “optional()” part off, you have to use a technique called “forced unwrapping”.  This is as simple as adding an exclamation point after the variable name in the code, as follows:

print( "The temperature is currently \(temp!) degrees.")

NOTE:  the “\(expression)” syntax above is a technique called string interpolation, and it’s a quick way to avoid having to do non-string to string data conversions in your code.  If I’d used string concatenation, I’d have had to convert the optional int temp to a String value.


In the next installment, we’ll discuss basic code constructs, like flow-of-control statements, code blocks, and function declarations.  In the meantime, if you have access to a Mac, I encourage you to play around with Xcode.  It has a really neat new feature called a Playground, which allows you to write Swift code “outside” the constructs and overhead of a full-blown application.  It’s exactly what it sounds like – a playground.  There’s instant feedback on compiler errors, you can write loops and see the result of code execution.


About Paul Horan

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

2 Responses to Swift for PowerBuilder Developers – Part I

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

  2. Pingback: Swift for PowerBuilder Developers – Part I | SutoCom Solutions

Comments are closed.