Category: iOS Dev

Going through “properties”, I’m not finding anything about private and public properties, or protected. I’m also not seeing anything about header files and class files, so at first blush it seems we can’t hide properties from other classes. How do we stop people from using the wrong properties?

That can’t be good. I must be missing something.

There’s a lot of good stuff in Swift, of course, but adopting Ruby’s block syntax seems a really nice idea. It’s called “trailing closures” in Swift, but it’s the same thing, as far as I can see. An example from the text:

let strings = numbers.map {
    (var number) -> String in
    var output = ""
    while number > 0 {
        output = digitNames[number % 10]! + output
        number /= 10
    }
    return output
}

Everything between braces is the block, um.., trailing closure.

Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks.

Function types are declared like:

var mathFunction: (Int, Int) -> Int

In this example: mathFunction is a variable that can hold any function that takes two Int as parameters and returns one Int. Fine, so far.

Functions can take such functions as parameters and also return them. For instance, a function taking a function like the above as parameter would be declared as:

func printMathResult(mathFunction: (Int, Int) -> Int) 

A function returning a function taking a Bool as parameter and returning an Int could look like:

func chooseFunction(choice: Bool) -> (Int) -> Int

Notice how the two pointer operators (->) mean to entirely different things. The first indicates a return value, the second is part of the function signature of the returned value.

Let’s imagine what a function type would look like if it takes a function of an Int, returning an Int as parameters, and returns a similar function:

func confusingFunction(number: Int) -> (Int) -> (Int) -> Int

I may very well have written that wrong, but can you tell? This is totally different from old school C declaration of function prototypes, but I’m far from sure it’s any easier to understand. Maybe judicious use of “function types” (or “typedefs” as we used to call them 30 years ago…) could make this clearer.

Function parameters now have distinct “internal” and “external” parameter names. The simplest form does away with named parameters when calling functions, that is, we can now do:

mysteriousFunction(15.2, "yeah, right", "only on a sunday", -1)

…just like in the good(?) old days of plain C/C++. Yes, you can force naming of parameters on the caller’s side, but it’s more work than the sloppy old way. Guess how often we’ll see that now? So, simple, inscrutable, and bug prone is the new default.

Looking over the “Swift” language Apple presented during the WWDC keynote. First off, declarations using “var” and “let” made me think of Basic, and had to stifle a gag reflex.

I’m reading the iBooks book on Swift. When I got to closed and halfopen ranges on page 100, I thought this was a big mistake. It’s very hard to see at a glance which is which. We’ve been trained for so many years to see ranges in for loops as closed, and react immediately if that expected “-1” as in “(0 to n-1)” or equivalent, is missing.

Sure enough, go to page 135 in the same book, and the example given is clearly wrong, where the author of the book confused the two. Two dots is a halfopen interval, three dots a closed interval, and the example is:

“shoppingList[4...6] = ["Bananas", "Apples"]”

(Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks.)

This is not going to end well.

Update: I was wrong. See the comments.