Swift: Properties

TL;DR : Properties.playground

Classes have properties and in Swift they are much like they have been in Objective-C, C# and Java which are languages I have worked with for years. Each are all very similar. What is very different about Swift is a strict optionals system as well as powerful type inferencing.

As a contrast, Java was released with a lot of excitement in a world with system languages like C and C++ on one side and scripting languages like Perl and Python on the other. And then there was JavaScript which was something else. With Java the types system was very strict. It was compensating for a type system in C and C++ which left open the door for many holes for both memory leaks as well as security exploits. Java also enforced a lot of organizational requirements. For example, a class has to be added to a single file by the same name and organized into a folder structure which matches the package structure. For anyone who found the scripting languages to be too fast and loose Java was the best thing ever and for most developers at the time Java was seen as the glorious solution that would become the last language you’d every have to learn.

Then Ruby came onto the scene and Google Maps breathed new life back into JavaScript. These scripting languages, with their syntax which was much less rigid, became all the rage. The way a scripting language could be much more expressive with much less code which took much less time to complete a working application was very attractive after many long Java projects spun out of control. In 2002 book named Bitter Java came out which expressed some of the frustration of working on Java projects which often applied patterns which were accepted as dogma yet were not reviewed critically before incorporating them into the requirements for a project. The “one size fits all” approach caused my Java projects to start with heavy boilerplates which did not offer the intended value. This is the year I saw many Java developers move over to Ruby a the term “Frontend Engineer” became a common term as AJAX became a common requirement for every website. The author of “Bitter Java” made the switch to Ruby and wrote books about the transition. These requirements in Java and the dogmatic patterns lead to a lot of frustration. With any new language I am critical of anything which appears to mirror what happened with Java in the early 2000's.

JavaScript does not have all these requirements or a strong type system, at least not like Java. Sure you could create a structure like types with JavaScript but it was not enforced by the engine which compiled and ran your scripts. There have been many techniques which emulate a type system in JavaScript. But it has largely been up to you to ensure your code was correct. This is where type inferencing comes in. Tools like Visual Studio started to interpret JavaScript in the IDE to infer the code tree and extract information from this loose type system. And it has not been easy.

With jQuery, a very popular library among Frontend Engineers, there were named functions which were actually generated from an array of strings. An IDE could not simply parse out all of the functions from the source files to know what is available. It had to interpret each script and observe the symbols which were created in order to infer what then existed in the live environment. The plugin system for jQuery was another challenge for inferring types or in the very least letting the developer know which functions existed so hints could be shown while writing the code and then also let them know if a function is being called correctly later, perhaps even ensuring the parameters being passed into a function are correct. Finally, there were many techniques for generating code on the fly which were not all recognized by type inferencing engines. This meant that if you were using Visual Studio in 2014 you had to use a techique that it understand if you wanted to benefit from the IDE features it could provide.

Building a type system on top of a dynamic language which did not start with types in mind is like building on top of sand castle. This effort was so difficult that TypeScript was created as a superset of JavaScript. With TypeScript it is possible to use types, as you the name cleverly suggests, and then generates JavaScript files which can be run in web browsers which won’t be able to understand TypeScript directly. It is like it is used as a form for the sand castle but it can be precise and create the exact JavaScript output you want and have confidence that it is correct. It is a good compromise for building complex web applications which must be run in our modern web browsers.

Back to Swift, we have a language built with both strong typings and dynamic language features in mind. And instead of having to infer the nature of the live environment from source code which could use various dynamic languages features as JavaScript does it has them baked into the syntax and supported by a powerful set of language tools called LLVM. Now a software engineer can be as meticulous as they could with Java yet as expressive and agile as they could with JavaScript or Ruby. It is the best of both worlds. I believe this balance between strong typings and dynamic is what makes Swift such an exciting language for most of the developers getting into it.

As I dig into Swift I keep this history in mind. I can write code quickly yet I have powerful protections from a rich set of language tools and for classes a big part of that system is properties. I’d estimate that easily more than half of mastering Swift will be in mastering properties. A property in Swift is so much more than it’s value. It may be strong, weak, unowned or lazy and it may also be optional. A property is often a reference to an instance of another object which sets up how classes behave with each other. Every modifier allows for a wide range of features and techniques to be possible. Many new patterns will become common with Swift which were not considered with other languages before. And many really great techniques have been published already.

In the first topic that I cover I just created a couple of basic classes with a couple of properties which are then accessible when printing out a description of each instance. It is quite simple to simple try out the syntax and to prepare for exploring properties in the next set of topics.

You can clone this resposity from GitHub and move to the “dev” branch where I have most of the current materials I am learning to dig into each topic on the checklist.

Next: Weak Vars

GitHub Gist