Autoresizing text view in table cells

Continuing from the previous version, I upgraded to Swift 3 and Xcode 8 (beta 4). Most of the glitches are gone, but every now and then one shows up. So I’m not entirely sold on the whole thing yet. I’m still having doubts if it wouldn’t be simpler to just have the user enter text in a separate popup of some kind, and only display read-only views in the actual table. The problem with that is that it is a lot less intuitive and user-friendly. OTOH, it would work… I get a feeling Apple really doesn’t want us to do editing in text views in table cells. I don’t think any of Apple’s own apps do that.

Continue reading “Autoresizing text view in table cells”

Server-side Swift

This presentation from WWDC 2016 boggles the mind. It completely overturned all my concepts about server-side nodejs and javascript in general. If you’re into docker containers or anything of the kind, and you develop in Swift client-side, this must be seen.

Let’s hope the project doesn’t die. Let’s hope I didn’t overestimate this.

Swift, missing idea #1?

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.

Swift, good idea #1

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.

Swift, bad idea #3

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.

Swift, bad idea #2

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.

Swift, bad idea #1

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.