Prévision et souhaits pour la WWDC 2015

Le grand pow-wow annuel de la pomme est presque arrivé. Voici ma (bien modeste) liste de choses que j’aimerais y trouver.

Prévision

  1. Un ABI stable pour Swift. Un ABI, ou Application Binary Interface, définit les conventions par lesquelles un bout de code définit dans un fichier source peut trouver et appeler un autre bout de code définit dans un autre fichier source. Lorsque Apple a introduit Swift l’an dernier, ils ont indiqué que l’ABI du langage n’était pas stable, mais qu’il le deviendrait « dans un ou deux ans ». Pour l’instant, cette instabilité fait en sorte que tous les fichiers source composant un logiciel (y compris ceux dans des librairies et frameworks tierce-partie) doivent être compilés avec une seule et même version du compilateur Swift. L’adoption d’un ABI stable aura les effets suivants :
    1. Il permettra la distribution, en forme binaire uniquement, de librairies et frameworks écrits en Swift.
    2. Par le fait même, il permettra à Apple d’écrire des frameworks de Mac OS et iOS en Swift, ce qui mènera naturellement à une éclosion de nouveaux patterns d’utilisation.
    3. Ce sera une indication supplémentaire du sérieux d’Apple vis-à-vis leur nouveau langage, incitant ainsi plus de développeurs à faire le saut.

Souhaits

Voici des choses que j’aimerais bien voir, mais pour lesquels je n’entretiens pas vraiment d’espoir.

  1. Interopérabilité entre Swift et C++. Actuellement, Swift est interopérable avec C et Objective-C. Les développeurs dont les applications ont des noyaux multi-plateforme en C++ (ex Microsoft et DropBox) sont laissés pour compte. J’avoue que ce n’est pas nécessairement dans l’intérêt d’Apple de faciliter ce genre de développement — ils aimeraient bien mieux que les développeurs écrivent 100% de leurs applications avec les langages bénis — mais ça faciliterait le développement d’applications à grande envergure, tout en démontrant encore une fois qu’Apple prend Swift au sérieux.
  2. Ajout des exceptions à Swift. Depuis l’introduction des « failable initializer« , je pense que mon chien est mort. Il est clair que Chris Lattner et cie n’aiment pas les exceptions. Ou plutôt, que la réalité — que Cocoa et Cocoa Touch ne sont pas conçus pour fonctionner correctement en présence d’exceptions — a eu raison des avantages que les exceptions peuvent procurer. Pourtant, certaines classes dans Cocoa lancent des exceptions « non-fatales », que le code Swift n’a aucune façon d’attraper. Actuellement, la « solution » à ce problème est de passer par un intermédiaire écrit en Objective-C. C’est clairement inacceptable à moyen terme; il faudra une solution, à tout le moins pour le côté « attrapage ».

Dialogue menant à la WWDC

Mercredi, 15 avril 2015

Elle: Est-ce que t’as vu, y a un truc sur la conférence? [NDLR: dans les médias qu’elle lit]
Moi: Mon amour, tu parles de la  WWDC ? Je me suis inscrit à la loterie hier!
Elle: Ça serait le fun d’y aller …
Moi: Tu veux aller à la conférence? Tu ne peux pas, t’es pas inscrite comme développeur Apple.
Elle: Non non, je veux dire aller là-bas, faire un voyage!
Moi: Tu voudrais venir avec moi? Mais tu t’ennuierais, non? Je vais être occupé du matin au soir avec la conférence.
Elle: Inquiètes-toi pas pour moi, je vais trouver de quoi m’occuper. Je vais aller visiter les phoques.
Moi: On pourrait y rester une semaine de plus, pour vraiment avoir du temps à nous.
Elle: Ça serait super, ça!
Moi: Donc, si je gagne la loterie on part tous les deux pour deux semaines. Sinon, on trouvera autre chose …

Le temps passe … Et la disponibilité des chambres d’hôtel pendant la conférence diminue d’heure en heure.

Moi: Mon amour, pourquoi est-ce que nos plans de vacances seraient contingents sur une loterie?
Elle: Qu’est-ce que tu veux dire?
Moi: On pourrait y aller, que je gagne ou pas.
Elle: Ô.. vraiment?
Moi: Il y a une conférence alternative qui se déroule en même temps, je pourrais faire un tour là de temps en temps.
Elle: Grand sourire et regard amoureux
Moi: Donc on est fixés. Trouvons l’hôtel et l’avion!

Donc, nous voilà fixés pour un voyage de rêve en Ca-li-for-ni-a … gagner la loterie, c’est presque du bonbon.

Returning Errors in Swift

Swift’s rich enumerations open up new possibilities for returning error information from functions. For example, for years Cocoa has had a convention whereby errors are returned via an out-parameter of type NSError. For example :

func executeFetchRequest(_ request: NSFetchRequest!, error error: NSErrorPointer) -> [AnyObject]!

What this method signature means is : If the method returns something, then the method succeeded and the returned something is an array; else, if the address of an NSError object pointer was supplied, make it point to an object that describes whatever error occurred. Sounds kind of like an enum to me.

Within application code, where Objective-C compatibility isn’t a concern, Swift will allow us to do this :

enum MyFetchResult
{
    case Success([AnyObject])
    case Error(NSError)
}

func myExecuteFetchRequest(_ request: NSFetchRequest!) -> MyFetchResult

...

switch (myExecuteFetchRequest(myRequest))
{
    case .Success(let results)
        // do something with results
    case .Error(let error)
        // do something with error
}

This approach has the advantage of avoiding polluting function signatures with redundant NSError arguments. Of course it does so at the cost of complicating the function result; however I think this approach will be somewhat less error-prone, especially if the function result is fed to a switch statement (like in the example above), which requires all possible values of the enum to be handled.

Retour sur les prévisions

Maintenant que j’ai eu le temps de digérer les vidéos de la WWDC (pas tous quand même!), voici mon auto-évaluation de mes prévisions :

  1. J’ai eu raison qu’Apple permettrait aux développeurs tiers de créer des modules, et aussi que ceux-ci serviraient entre autre à réduire les collisions de noms. Par contre j’ai prédit aussi que ces développements se feraient « à pas de tortue », ce qui n’a vraiment pas été le cas! Heureusement, je n’ai pas prédit qu’Apple ne présenterait pas un nouveau langage de programmation …
  2. Je n’ai pas eu raison par rapport au cryptage des données téléchargées en arrière-plan. NSURLSession permet de spécifier des NSURLProtocol maison — ce qui aurait pu être la porte d’entrée du cryptage — mais seulement pour les sessions qui ne sont pas en arrière-plan. Peut-être l’an prochain …
  3. On peut dire que j’ai eu raison sur la « profondeur » des changements dans l’interface utilisateur de OS X. Je pense que les applications existantes peuvent s’adapter au nouveau look sans avoir à changer leur code de façon significative.

Prévisions WWDC 2014

J’ai quelques modestes prévisions de ce qui sera annoncé cette semaine à la conférence de développeurs Apple. Contrairement à ce que font la plupart des prognosticateurs, je m’en tiens surtout à des choses plutôt bas-niveau.

  1. Apple continuera à améliorer à pas de tortue son support pour le développement «in the large». Plus précisément, je pense que le concept de module, introduit l’an dernier, sera amélioré de façon à permettre aux développeurs tiers d’en créer. Je pense aussi que les modules serviront éventuellement (mais pas nécessairement cette année) à isoler les symboles applicatifs de ceux de l’OS. Cela réduirait les collisions (noms de classes, sélecteurs, etc) qui sont la source de biens des soucis sur iOS et OS X.
  2. NSURLSession sera amélioré pour permettre le cryptage des fichiers téléchargés ou téléversés en arrière-plan. Actuellement ces fichiers ne sont pas encryptés, ce qui empêche l’utilisation de cette technologie dans des domaines ayant de fortes exigences réglementaires tels que la finance et la santé. C’est le seul maillon manquant de la chaîne, car les donnés peuvent être cryptées (via SSL) sur le fil, et elles peuvent l’être aussi dans des fichiers créés directement par l’application.
  3. S’il y a cure de jeunesse pour l’interface utilisateur de OS X, je pense que ça sera plutôt superficiel. Le look va changer, mais pas les APIs en arrière. Le contraire serait difficile à justifier côté coût-bénéfice, à mon avis.

Mon premier billet

Je me présente : Paul Lalonde, programmeur informatique.

Ça fait des années que je me dis que je devrais avoir un blogue. Une présence sur la toile, quoi. Un endroit où je pourrais écrire ce qui me passe par la tête, et qui accepte volontiers des textes plus longs que 140 caractères…

Cette présence sera donc ici.

Comme je suis un néophyte total en WordPress, je demande l’indulgence de mes lecteurs. Il y aura sûrement beaucoup d’expérimentation tant dans le contenu que dans le contenant dans les semaines et mois à venir.