Tuesday, 17 June 2014

Slight Detour into Custom Sequences

Still trying to work my way around the Swift collection hierarchy with a view to working out mapping functions which work across all collection types (examples so far are Array only) - must say not the easiest thing to get your head around.

In doing my investigations however made a slight detour into understanding how it's possible to extend the collection (Sequence being the root) hierarchy and have your custom collections available to the for value in mysequence enumeration operations.

A very simple, but working, example is shown below which simply takes and array of integers and enumerates over them returning a tuple of the value and the value * 2.

I do have to say the string interpolation feature of Swift is really nice - even type checks (correctly in the main!)

Saturday, 14 June 2014

Pipe and Chains!

In the post written so far I've touched upon implementing the (|>) pipe forward operator and various of the traditional functional (in so far as Swift allows) mapping and folding options but haven't really touched upon why these can be useful in the software development process.

The code sample below shows how, when combined, they provide a powerful mechanism which can greatly reduce the amount of code a developer needs to write. As a side effect you should also note a distinct lack of more traditional control structures (condition,loops etc) and variable definitions.

The code is type checked by the compiler and handles, by using Swift option chaining, the optional elements within the model hierarchy.

Another helper function has been introduced here (getOrElse) which lets us provide default values for optional variables - in the cases here simply ensuring an empty array is returned as part of the search if any part of the model chaining is optional.

Tuesday, 10 June 2014

Playing with fold

Quick bit of code showing how a basic 'fold' can be applied to Swift Arrays.

Swift Singletons

I've seen some questions flying around about how to write singletons in Swift and I thought I'd have a play to see what I could come up with. On the surface either of the first two techniques presented here appear to function as expected but with big gotchas. The third solution seems to achieved the desired aim, although they all suffer from an issue which I'll discuss at the end of this post.

Swift currently lacks any notion of public/protected/provide (one would assume this will come over time maybe) and also gives the developer no opportunity to define variables at class scope (statics) - using structs would appear to be a way around this and it is something which is explored in the code below.

Version 1 better represents the traditional Objective C approach (although the static is usually captured within the function - something we can't do here) - we do however expose the done and instance statics behind the implementation and these can be overwritten as shown in the test code.

Version 2 removes the requirement for the done but suffers from exactly the same problem as before in that the instance can be overwritten.

Version 3 seems to fix the ability to overwrite the underlying static and appears to achieve our stated goal.

So have we arrived at a solution?

What about if we now define these as 'global' variables
let v1 = MySingleton(123.45)
let v2 = MySingleton(234.56)
let v3 = MySingleton(345.67)

We've now got 3 separate instances - clearly not what we wanted.

I've seen this mentioned on the forums and originally suggested by Apple engineers as the solution to this problem. I guess it relies on convention and the developer only creating one such instance.

Until we can hide the initialiser then I guess we can't have a real solution to the problem (disclaimer - I haven't finished reading the language spec yet so perhaps something in there will help find a solution)

Sunday, 8 June 2014

Partioning Arrays

Been taking time to try and decipher the Swift collection hierarchy (with minimal success) and understanding CloudKit (looks promising and will feature in later posts) so not had much time to finish off the async example posted earlier.

The issue with the ! operator if anyone guessed is the fact that the result wouldn't actually get calculated until after the async call had finished as it was wrapped in a closure which had delayed execution. 

Anyhow, a bit more code to keep things going. Partioning and Choose this time, both making use of the |> operator discussed earlier.

The purpose of these functions will become more apparent as time progresses and things build up into more concrete examples.

Friday, 6 June 2014

Hiding GCD - (Or a very rough attempt at doing an Async!)

Just a bit of code today - some thoughts on hiding GCD usage behind an f# like async facade (bit difficult without monads but there you go)

When I've fine tuned this I'll give a more detailed commentary.
It does compile and run quite happily.

UPDATE: There's a pretty fundamental error in the code below (red wine was involved during the creation process). I'll leave as is for the moment to see if anyone can point it out and fix it later. As a clue - it's in the (!) operator code.

Thursday, 5 June 2014

Swift Pipe Forward

Update: A follow up post is now available showing how pipe can be used (Pipe and Chains!)

Just a quick one today as I'm busy contemplating on Swift exceptions (or more precisely the fact that I think it's a good idea that it doesn't appear to have them (yet?) - Good debate with +Simon Cousins  earlier in work on the subject)

Anyhow, a little bit of Swift code showing how the F# pipe forward operator, touched on earlier, can be implemented. Look closely and you'll see some currying,generics and string interpolation in action.

I'll admit I need to look more into the options available for the 'operator' keyword and associativity parameters but the setup here works quite nicely at the moment. What's not immediately apparent is that types are maintained and checked throughout, although I'm not fully convinced yet that the Swift compiler isn't bug free - it could certainly look to f# in this regards and the hover over intellisense which proves invaluable, particularly where types are inferred.

Pop over to GitHub to see full workings out

Wednesday, 4 June 2014

Swiftly Does It!

Welcome to a new blog dedicated to understanding the new Swift programming language introduced by Apple for creating iOS and OS X applications. In my day job I work creating Enterprise level F# and Scala applications with a heavily functional bias and the aim of this blog is to understand how elements of those languages can (or can't) be implemented in Swift.

Here's a quick example piece of F# to start us off.

Source: Wikipedia

Wouldn't it be nice if we could write something similar in Swift like this

Well you can! The code above is perfectly valid Swift - it's just missing definitions for map and filter and the important (|>) operator which we'll cover in the next post (Note Swift collections come with a prebuilt definition of map but we'll create a new one here just for demonstration purposes)

Follow me: