Tuesday, November 22, 2016

A Pragmatic View of Looping Constructs in Swift 3.0

As most developers who use Swift are probably aware, the traditional 'C-Style' for-loop has been deprecated - and outright disdained - in version 3.0 of the language.  A prototypical example follows:

Ex 1:
for (int i = 0; i < 100; i++)
{
// Whatever meaningful thing needs to be done 100 times

}

In Swift 2.x, this syntax is discouraged, but in Swift 3.0 it is removed altogether.  Now, in the Swift language manual, Apple explains how this can be accomplished in modern syntax:

Ex 2a - exclusive end index (does not include 100):
for i in 0 ..< 100
{
print(i);

}

Ex 2b - inclusive end index (includes 100):
for i in 0 ... 100
{
print(i);

}

That about does it for our trivial example.  Almost every real-world usage is more complex than this so I wanted to delve into those scenarios for the sake of other developers (and myself once I have forgotten).  First off, there is the incrementer expression ('i++' in Example 1).  In Java, I often write an incrementer other than i++:

Ex 3:
for (int i = 0; i < 100; i += 2)
{
// Whatever meaningful thing needs to be done 50 times

}

There is a straightforward answer for this:  The where clause:

Ex 4a - exlcusive end index:
for i in ..< 100 where i % 2 == 0
{
print(i);
}

Ex 4b - inclusive end index:
for i in ... 100 where i % 2 == 0
{
print(i);
}

The downside of the where clause is that the runtime still counts all the values that don't match the where clause.  I.E., in the loop in Ex 4 the runtime follows this process:

0:  Initialize i to 0.
1:  Evaluate where clause.  If False skip to step 3:
2:  print i (Loop body)
3:  Increment i by 1.
4:  Is i < 100?  If so go to 1:

So, if your loop skips a lot of steps, or in other words uses a large increment, then this would waste a lot of cycles.  But, take heart, there is an answer for this as well:  stride.

Ex 6a - exclusive end index:
for i in stride(from: 0, to: 100, by: 2)
{
print(i);
}

Ex 6b - inclusive end index:
for i in stride(from: 0, through: 100, by: 2)
{
print(i);
}

The stride function actually returns a struct that serves as an iterator, so there is likely no allocation of memory since this can easily be accomplished in 1 variable.  However, what about the case where you need to access not only the current value of the loop, but also the index within the loop itself?  E.G., the loop in Ex 6a might have an i value of 2, but the loop index is 1.  This is accomplished using the enumerated function:

Ex 7:
for (index, j) in stride(from: 0, to: 100, by: 2).enumerated()
{
print("\(index): \(j)");
}

The enumerated function returns an iterable set of tuples, and according to the names you provide will contain the loop index as the first variable name and the array value in the second name.  In other words, the declaration in Ex 7 might as well be (Laurel, Hardy) as (index, j).  In that case, Laurel would be my index and Hardy would contain the value.  The order matters, not the labels.

In order to use enumerated, you have to be working with an object of some sort, either a Strideable as in Ex 7, or else some other appropriate type such as an array, as in Ex 8, but it can't be a plain numeric range:

Ex 8:
let arr: [Int] = [0, 2, 4, 6, 8];

for (index, j) in arr.enumerated()
{
print("\(index): \(j)");
}

Reverse loops are something I have really not ever had much need of (reverse counting loops).  For reverse counting, I usually use an upward counting loop with a calculation for the downward counting value.  Nonetheless, these can be accomplished in many of the same ways except that it always requires a more complex interaction over the traditional loop:

Ex 9 - simple reverse iteration:
for i in (0 ..< 100).reversed()
{
print(i);
}

Ex 10 - simple reverse iteration with where:
for i in (0 ..< 100).reversed() where i % 2 == 0
{
print(i);
}

Ex 11 - simple reverse iteration with index:
for (index, i) in (0 ..< 100).reversed().enumerated()
{
print(i);
}

Ex 12 - reverse iteration with stride:
for i in stride(from: 0, to: 100, by: 1).reversed()
{
print(i);
}

Ex 13 - reverse iteration with stride and index:
for (index, i) in stride(from: 0, to: 100, by: 1).reversed().enumerated()
{
print(i);
}

Ex 14 - reverse iteration with stride and a negative increment.  May not be 'proper', but it works:
for i in stride(from: 100, to: 0, by: -1)
{
print(i);
}

"Wait", you say, "What about the case where I have to loop with . . . <blah> <blah> <blah> <some special circumstance>???!?"  There is always some special circumstance which can't be accounted for in the language itself without making everything too complicated.  The fallback answer is the trusty while loop:

Ex 15 - loop starting with my Aunts' age, skip 17039 days until you reach my julian birth date
let julianBirthday = 2440131;
let myAuntsAge = 31;
let unusualInterval = 17039;

var loopIndex = 0;
var counter = myAuntsAge;

while(counter < julianBirthday)
{
print("\(loopIndex): \(counter)");
counter += unusualInterval;
loopIndex += 1;
}

Ex 15, besides being completely useless, demonstrates that the basic while loop is much more tedious to build but contains enough to handle just about any situation.  It is also not a very good example, because it can be written using the simplified versions:

Ex 16 - our loop was really not that special:
for (loopIndex, counter) in stride(from: myAuntsAge, to: julianBirthday, by: unusualInterval).enumerated()
{
print("\(loopIndex): \(counter)");
}

Wednesday, February 24, 2016

Swift asserttions

I just ran across this today.  It's pretty cool - assertions in swift can be implemented using a closure shorthand which runs efficiently.

Saturday, November 28, 2015

(Im)Proper way to end an iOS app . . .

I am very new to Swift and iOS programming in general, and I had a situation where I wanted to throw an exception to fail an app in an unacceptable situation, and all I knew to do was to call exit(1) in plain old C-fashion.  I put that in my code like on the first day, and I forgot about it.  Since then I have had a lot of bizarre problems with XCode like not running my tests and just logging weird errors like "Failed to bootstrap" and other things.  I finally figured out that was what was causing the errors, and instead I could use:


    fatalError(@autoclosure message: () -> String = default, file: StaticString = default, line: UInt = default)

E.G.

   fatalError("You did something dumb.");

and it accomplishes the same thing (tells me I have done something stupid), but now the debugger stops on that line of code so I remember exactly what I have done.

exit(int), don't use it.

By the way, this is something that only a developer could do, clearly this would not be the way to handle an unexpected user condition.

Tuesday, November 24, 2015

Preach it, brother.

I came across this post today.


I especially like this:  “There is a fundamental difference between the few developers that will become highly skilled and all the other copy and paste developers. The former know they lack knowledge and take the time to grow it. The latter never bother, they go on with what little they know, trying to hack together something and calling it a day.”

Life can be frustrating as a dig-in-and-find-out-how-it-works developer, but I have always admired someone who will dig into something, endure the frustration and "What were they thinking???!?" moments, and come out on the other side with an actual understanding of how something works.

Wednesday, November 4, 2015

Swift Protocol-Oriented programming

Apple makes a big deal about Protocols in swift and how they are better than anything else ever.  I found it quite irritating that nowhere in their explanation of what makes them so great did they mention that a protocol is eerily similar to an interface in Java.  Moving from a C++ background to Java, I was completely baffled why you would use an interface rather than an abstract class.  That question was answered back in 1997 when I started designing applications and APIs using interfaces first.  Nowadays, moving into swift, protocols certainly have features that interfaces do not - such as extensions and conditional conformance - but really - this is not something they just pulled out of nowhere.  I wish they didn't have to act like every thing they do is new and unprecedented.

It would be so much more honest for them to come out and say, "In designing a new language, we looked at what works in Java, Lisp, Python, (gasp) Perl, Haskell, Go, JavaScript - the needs of iOS and the environment apps find themselves in - and created a best-of-breed language."

Swift 2.0, Reference and Value Types, and Unintended Sharing.

I have recently begun learning swift 2.0, because I would like to build an iOS app and I really don't want to have to learn Objective-C.  I am trying to learn it the right way, which means understanding how the language works and not just mutating examples to learn by accident.

I have been reading a lot about structs and classes, and the difference between value types and reference types.  In short, classes pass around object references and structs make copies whenever you pass them around.  I visualize it in old-school terms:  Classes use pointers, but with structs the variable IS the data.

This seems pretty simple - especially if you are comfortable with object languages.  I have watched a few Apple videos, though, and they make it sound revolutionary.  This one in particular goes on about unintended sharing - I pass a handle to the same object into two different contexts where they are expected to be independent.  Change one, impact the other, etc.  His illustrative example was "I created a thermostat object, assigned it to my house.  Then I set the thermostat in my oven to 450, and my house caught on fire!"  Paraphrase.  Gag - what a juvenile way to introduce a language feature.  They could have at least used a real-world scenario they came across implementing their standard libraries that made this feature such a deal-maker.

This seems to me to be very valuable to a college student, or someone learning an object language coming from C, but really, is this that big of a deal?  I can honestly say that I haven't had a bug of this type in my code, that I have detected of course - for decades.  On the other hand, I just spent an agonizing couple of days trying to figure out why extremely routine code did not work.  Take this example:

var map = [String: [String: String]]();
var subMap = [String: String]();
map["map"] = subMap;

subMap["1"] = "2";

For those who don't know swift, this means create a map which can hold maps of string value/pairs.  Next, create a string value/pair map, and assign it to the key "map" in the top-level map.  Finally, assign the key/value entry "1" -> "2" into the sub map.  The expectation being that it will be reflected in the top-level map as well.  This is pretty standard in Java - I do it a lot so I can factor code which handles the sub trees into external code.  In this case, it doesn't work.  Because collections in swift are structs - I.E., value types - the assignment on the third line makes a copy which is unaffected by the assignment on line 4.  I came up with this working code after much hair-pulling:

var map: Dictionary = [String: [String: String]]();
map["map"]!["1"] = "2";

And only later uncovered the reason that I explained before.  I find this extremely annoying, but certainly manageable once you understand the language - and maybe even something you can use effectively.  But I found his example so contrived that I basically checked out.

Wednesday, July 29, 2015

Java FX Event Thread vs AWT Event Thread Brawl

So, I recently started working on a Java UI application focussing on my backend first, then the UI components.  I am not very good at making pretty swing UIs (very out of practice - but I was really active when Swing was in development - what was that, 1997?  :| ).  I have done a lot have dynamic web development over the last decade and am frankly shocked that swing UIs are so far behind.  A dynamic swing UI to match a trivial web interface would be a LOT of work.  So, my first cut at my UI was targeted at behavior and testing, which was a substantial effort - I would have thought automated unit testing in the user interface would be in a better state than it is.

Almost every substantive UI testing platform appears to be abandoned (uispec4j, abbott, others I can't remember anymore) so I decided to build my own support as I needed it (Not building a generified UI unit testing framework - just what I needed).  The one good thing that came out of this approach was I realized testing the UI through the UI - as a user would or a record/playback testing method - was a big mistake.  I was decomposing my user interface as any good developer would do, but my testing was completely monolithic.  Instead, I started testing components at the finest grain and my tests became so much faster and easier to write with less bulk.  I also wired components together to rely on messages between objects rather than having handles to each other.  Sound familiar?  That should have been my approach from the start.

At any rate, I was going along, and decided it was time to make the user interface better, and I thought it might be time to look at Java FX.  One of the major factors was Oracle choosing FX as the future direction for java, but also the ease with which you can externalize the building of the user interface into fxml files.  That is huge.  I can use a builder and not be tied to a tool like eclipse or IntelliJ - big win.

I made a refactor which permitted me to transition from swing to Java FX as it seemed desirable, and even encouraged with the addition of JFXPanel.  This seemed ideal since rewriting the entire UI all at once sucks.  Well, this sucks worse.  The Java FX Event thread and AWT Event thread are entirely incompatible - so threading in the UI is a nightmare.  Consider as an example a Swing Button action handler which needs to update the state of an FX node - you would have to do that asynchronously, you can't call PlatformImpl.runAndWait from the AWT event thread - it will hang a lot of the time.  But if your button action handler needs to wait until the FX node is complete updating - such as if the update triggers another event handler - you have to do it all asynchronously with a lot of calls back and forth into the different event threads and you are left with a real mess.

To compensate - I have had to convert all messaging in the GUI to asynchronous - which makes unit testing a major hassle because obviously test code needs to wait until things are done before making assertions.  The bottom line to me is not to do this.  Transitioning to Java FX should be done at least at the Frame level - or Stage in Java FX parlance - and don't let messaging in the GUI depend on passing between the different systems.