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.