In the previous posts we coded a fully functional JSON parser completed with error handling and independent from the source of the data (the reader).

In the parser we used also a custom operator >>> to invoke a function on an optional (if this is not nil) and return the result.

Now we are going to refine it and, in the way, see other custom operators.

Continue reading Swift JSON Parser – Part 4 →

Sometimes it happens to me to observe my code and to say: “no, these things should be made differently”. Then I go into “refactoring”. I think this is an important step of every programmer. Don’t be afraid to refactor (don’t listen to the voice inside you: “… don’t touch that code! Nothing will work correctly after changing this single byte …”): code is something always in evolution (and in test …).

Seeing the code of Part 2 I don’t like two different callbacks to be passed to the start method:

Continue reading Swift JSON Parser – Part 3 →

In this post we continue the development of a JSON Parser starting from the previous one: Swift JSON Parser – Part 1.

Let us begin handling the “something went wrong” part.

Error handling strategy

Two types of “bad things” can happen:

1. The parser has an error before looping on the elements of the array: this can be a reader error or the json returned is not of type [AnyObject?]
2. The parser starts but has an error on one of the element inside the loop

Continue reading Swift JSON Parser – Part 2 →

This is the first part of a multi-step process in which we will build a JSON parser in Swift.

In this first post we will see, among others, the following swift features in action:

• optionals
• enum with associated values
• curried functions
• typealias

Continue reading Swift JSON Parser – Part 1 →

 Currying is a generic “technique of translating the evaluation of a function that takes multiple arguments into evaluating a sequence of functions, each with a single argument” (wikipedia). Swift supports currying as we see in the following example.

Continue reading Swift curried functions →

 Dichiariamo in swift una funzione che prende come parametro una stringa e una closure:

Come si vede la closure (getPrefix) è usata internamente per ottenere il prefisso da inserire prima della stampa della stringa.

Continue reading Swift @autoclosure →

 La Beta3 di iOS8 e Yosemite ha portato alcuni cambiamenti in Swift abbastanza rilevanti. Forse dovremo abituarci a queste modifiche da qui alla uscita ufficiale, ancora molte cose mancano o sono da completare (per esempio le public private protected sui membri delle classi ancora non si vedono).

Le modifiche sono:

• Gli array ora hanno un comportamento nelle copie identico a dictionary e string, cioè per valore (non reference). Prima di questa modifica gli array in alcuni casi non venivano copiati ma condivisi fra più variabili (shared, per motivi di performance). Il metodo unshare per gli array non esiste più.
• L’operatore range non inclusivo (half closed) è diventato ..< (prima era solo ..)
• Nuova sintassi breve per array: [String] (quella di prima “String[]” continua ad essere valida ma si preferisce la nuova)
• Aggiunta una seconda notazione shorthand per i dictionary: [KeyType: ValueType], esempio: var myDict : [String, Int]

 Il nuovo linguaggio Swift introdotto da Apple alla WWDC 2014 sarà il linguaggio ufficiale con cui sviluppare App per iOS (e per MacOSX).

Già si discute molto se (o quando) l’Objective-C sarà completamente rimpiazzato. Io credo presto, anche se al momento ne abbiamo ancora bisogno per alcune funzionalità non  ancora pronte in Swift (provate a trasformare una stringa in float).

Una delle caratteristiche per me più innovative in Swift sono gli optionals. Per quanto ne so non esiste analogo in altri linguaggi (attendo smentite).

Continue reading Swift optionals →

 Sappiamo che Swift promette di essere più veloce di Objective-C. Al momento non si eseguono benchmark perché il nuovo linguaggio è ancora in beta ma già immaginiamo il perché di tale miglioramento delle prestazioni.

In questo interessante articolo di Mike Ash (trovato via Dave Verwer) noto due cose interessanti:

• La superiore velocità di Swift non sarà  data solo dall’uso delle vtable (in Swift le classi hanno già al momento della compilazione un tabella degli indirizzi dei metodi d chiamare) rispetto al dynamic bind (Objective-C aspetta il runtime per decidere e calcolare l’indirizzo dei metodi). Il compilatore potrà applicare ulteriori ottimizzazioni riguardanti, tra l’altro, la allocazione della memoria e un efficiente uso dei registri.
• Sembra che addirittura Swift sarà in alcuni casi più veloce del C. Questo perché l’uso in C dei puntatori ha come effetto l’aliasing che in alcuni casi impedisce l’ottimizzazione del codice stesso.

Buona lettura.