Tu parles de fonction sans paramètre d'entrée ni de sortie OK... alors pourquoi pas: ?
func times(func task: ()->() ) {}
Soit on déclare, soit on ne déclare pas... Evidemment, ça bugue.
On est obligé de mettre les 2 premières parenthèses aussi puisque pas d'argument d'entrée ? Réponse du compilo: oui...
Heu... j'ai rien compris à tes questions ^^
1. On met les parenthèses vides en entrée et en sortie puisque le type représentant une fonction c'est "(ParamsEnEntrée)->(ParamsEnSortie)" et qu'ici il n'y a ni params d'entrée ni de sortie. Tu voudrais mettre "->()" sans les "()" devant ? ou "()->" sans les "()" derrière ?! Ca serait un peu bizarre...
Le type Swift "()->()" est exactement comme le type Objective-C "void(^)(void)". Mais si tu préfères tu peux aussi utiliser "Void" à la place de "()" pour représenter une liste vide de paramètres. Ca te semblera peut-être plus lisible ?
2. Avec le mot clé "func" tu déclares une fonction, avec son nom et son corps. Donc "func" va en début de ligne ou démarrer une déclaration, exactement comme les mots clés "class" ou "struct". Le mot clé "func" ne serait donc pas à sa place à l'intérieur de paramètres d'une fonction.
Si le paramètre "task" était un "Int" et pas une fonction, tu ne mettrais pas "var task: Int", (car "var" est fait pour déclarer une variable) donc là y'a pas de raisons de mettre "func task: Void->Void" (car "func" est fait pour déclarer une fonction). Dans tes paramètres tu ne mets que "nom: Type", donc là c'est pas "x: Int" c'est "task: Void->Void", c'est pareil. Faut pas chercher plus compliqué, la syntaxe est consistante.
Sinon, en Swift les fonctions et les closures ont le même types. On peut voir "func" comme un mot clé servant juste à "donner un nom constant à une closure". Ainsi, on peut voir ces 3 lignes comme équivalentes :
// fonction nommée "toto" qui prend un Int et retourne un Double :
func toto(Int)->Double { ... }
// closure qui prend un Int et retourne un Double, et qu'on a associée à la constante "toto" -- Syntaxe 1
let toto: (Int)->Double = { x in ... } // Type de "toto" explicite, type de l'argument x inféré comme étant Int.
// closure qui prend un Int et retourne un Double, et qu'on a associée à la constante "toto" -- Syntaxe 2
let toto = { (x: Int)->Int in 2*x } // Type de "toto" inféré, type de l'argument et du retour explicites
Dans tous les cas, le type de "toto" est "(Int)->Double", autrement dit "un fonction ou closure qui prend un Int et retourne un Double". Une fois déclaré, Swift ne fait plus la différence que ce soit une fonction ou une closure (enfin en interne peut-être, si, j'en sais rien, mais en tout cas en pratique ils sont totalement interchangeables)
Si le paramètre "task" était un "Int" et pas une fonction, tu ne mettrais pas "var task: Int", (car "var" est fait pour déclarer une variable) donc là y'a pas de raisons de mettre "func task: Void->Void" (car "func" est fait pour déclarer une fonction).
Là , tu marques un point.
Sinon, en Swift les fonctions et les closures ont le même types. On peut voir "func" comme un mot clé servant juste à "donner un nom constant à une closure".
Ainsi, on peut voir ces 3 lignes comme équivalentes :
// fonction nommée "toto" qui prend un Int et retourne un Double :
func toto(Int)->Double { ... }
// closure qui prend un Int et retourne un Double, et qu'on a associée à la constante "toto" -- Syntaxe 1
let toto: (Int)->Double = { x in ... } // Type de "toto" explicite, type de l'argument x inféré comme étant Int.
// closure qui prend un Int et retourne un Double, et qu'on a associée à la constante "toto" -- Syntaxe 2
let toto = { (x: Int)->Int in 2*x } // Type de "toto" inféré, type de l'argument et du retour explicites
Dans tous les cas, le type de "toto" est "(Int)->Double", autrement dit "un fonction ou closure qui prend un Int et retourne un Double". Une fois déclaré, Swift ne fait plus la différence que ce soit une fonction ou une closure (enfin en interne peut-être, si, j'en sais rien, mais en tout cas en pratique ils sont totalement interchangeables)
J'ai jamais autant entendu parler des closures que depuis la sortie de Swift... Quelle en est la raison ?
Plus sérieusement tout simplement parce qu'avant Swift on avait déjà les closures (en Ruby, en JavaScript, en Objective-C...) mais on ne les utilisait pas forcément à leur pleine puissance... ou alors on ne les appelait pas comme ça tout simplement.
Et parce que ce qu'on appelait "block" en Objective-C on l'appelle "closure" en Swift (alors que les blocks en ObjC étaient des closures)
Avec Swift d'une part toute fonction n'est rien d'autre qu'une closure qui a un nom (constant) associé, mais en plus avec la syntaxe des "training closures" (la même que celle que tu connais en Ruby mais qu'on avait pas en ObjC) ça rend les closures vachement + sexy.
tab.map { 2*$0 } // comme un block en Ruby
tab.filter { $0>0 } // pareil
tab.map(uppercaseString) // en Ruby on passerait un Proc via "&:uppercaseString"
tab.map(-) // je sais même pas si on peut faire ça en Ruby!
Les closures de Swift c'est le combiné de ce qu'on trouve en Ruby avec les blocks + les Proc + les lambda + les fonctions + les opérateurs... c'est un type unique pour les gouverner tous ^^
Plus sérieusement ça ouvre des perspectives avec de nouvelles fonctions sympas qu'on avait pas en ObjC du coup ils en sont fiers ;-)
Ce qui me semble important n'est pas tant le langage (tant que c'est de la POO, aucun problème) mais les "classes mères" que l'on dérive pour construire son logiciel. Celles de Cocoa pour l'interface graphique sont nombreuses et puissantes, simples et souples d'emploi. En sera t-il de même pour Swift? A moins que l'on ne puisse utiliser les mêmes... (Il faudra que je lise la doc à ce sujet, pour l'instant je galère avec Core Audio/iOS...)
D'ici quelques années les API seront en Swift. Je me suis accroché au Pascal (+objets) aussi longtemps que j'ai pu et j'ai raté le passage sur Objective-C de plusieurs années. Pas question de refaire la même erreur.
Cela dit, j'ai eu un petit sursaut de nostalgie en découvrant le mot-clé override...
Pour l'instant, je découvre le playgroud et aligne les erreurs...
Oui on peut. C'est un nouveau langage mais qui peut tout à fait interoperer avec ObjC et qui est même directement bridgé avec Cocoa.
D'ailleurs ils le montrent dans à peu près toutes les démos. Genre les démos où on voit Playground dans lequel ils font des animations CoreAnimation et font bouger des sorites SpriteKit & co
En parlant de syntaxe, je me suis retrouvé avec quelque chose qui m'a paru bizarre. Dans la fonction touchBegan j'ai écrit ceci :
override func touchesBegan(touches: NSSet, withEvent event: UIEvent) {
let touch: UITouch = event.allTouches().anyObject() as UITouch
}
Le "as UITouch" ("as" que je retrouve assez souvent) me fait un peu bizarre et me parait beaucoup moins claire que "[[event allTouches] anyObject]"... M'y suis-je mal prit ? Qu'en pensez-vous ?
Le problème ici (comme évoqué dans l'autre sujet ici) est que tu utilises le bridging, autrement dit tu utilises ici des APIs qui sont encore en Objective-C, et qui sont traduites à la volée en Swift.
Sauf qu'en ObjC, anyObject retourne un "id". Donc un truc "on sait pas trop ce que c'est". Alors qu'en Swift, les tableaux sont typés avec le type de leur élément. On a String[] (ou Array<String>) pour un tableau de String, Int[] (ou Array<Int>) pour un tableau d'entiers, etc.
Là vu que le code ObjectiveC de [[event allTouches] anyObject] retourne un id, en Swift ça se traduit par un "AnyObject[]!" (l'équivalent d'un tableau de "id" si tu veux). Le cast doit alors être explicite pour pouvoir ensuite utiliser touch comme un objet UITouch.
Je pense (j'ai pas testé) que tu pourrais laisser Swift inférer le type de ta variable "touch"
let touch = event.allTouches().anyObject() as UITouch
Et il devrait pouvoir deviner que ta variable devra être de type UITouch. Par contre ça ne m'étonnerai pas que tu ne puisses pas faire l'inverse (forcer le type de ta variable "let touch: UITouch" mais ne pas faire le casting "as UITouch") car un cast de AnyObject vers autre chose (ici un UITouch) doit être explicite, surtout qu'il peut échouer (si jamais y'a un problème et que ton tableau event.allTouches() contient des objets autres que des UITouch et qui ne peuvent pas être convertis en UITouch).
Je pense (j'ai pas testé) que tu pourrais laisser Swift inférer le type de ta variable "touch"
let touch = event.allTouches().anyObject() as UITouch
Swift infère le type sans problème dans cet exemple (grâce au "as" qui correspond à un cast en C/C++/Objc).
Par contre je ne pense pas qu'il vérifie la compatibilité des types (faut que je relise la doc...), car pour cela il existe un opérateur de "downcast" "as?", qui va vérifier que l'objet casté est bien compatible avec le type demandé. Cela n'a pas d'équivalent en ObjC et correspond au "dynamic_downcast<T>" de C++.
let touch = event.allTouches().anyObject() as? UITouch
if let aTouch = touch {
// J'utilise aTouch ici
}
Dans mon exemple, j'utilise "as?" (ce qui n'a aucun intérêt ici, mais c'est pour l'exemple). Le résultat étant optionnel, il faudra passer par une phase d'unwrapping pour utiliser l'objet. J'utilise l'optionnal binding pour créer une nouvelle constante aTouch en unwrappant la constante optionnelle touch. On n'entre dans le if que si la constante touch avait une valeur.
Personne n'a parlé du pattern matching des swicth ?
Je trouve pourtant ça intéressant, et ça ressemble à ce qu'on peut trouver dans ocaml.
L'inférence des types aussi est intéressante pour les variables/constantes locales.
La syntaxe d'indication des types ressemble à se qu'on trouve dans les langages ml.
(Dans les langages ML une fonction qui prend 2 entiers et renvoi 1 chaine de caractère possède ce type, Int -> Int -> String, c'est très pratique pour faire de la curryfication, composition, renvoyer des fonctions etc...)
En faite je trouve que Swift se rapproche syntaxiquement d'un langage fonctionnel.
Je trouve que l'utilisation de tuple de valeur est top (pour le retour multiple par exemple). Surtout qu'on peut avoir des tuples nommé, et statiquement typés !
Par contre, quitte à faite un nouveau langage ils auraient pu:
* Ajouter les namespaces (J'ai vu dans la doc la notion de module, mais j'ai pas trop compris)
* Ajouter la visibilité private, public, protected (apparemment c'est prévu pour une prochaine version)
* Et garder les exceptions avec try catch. Là on ne peux plus gérer les exceptions et je trouve ça dommage. Même si ce n'était pas très utiliser en objective-c, c'est quelque chose d'extrêmement pratique pour remonter les erreurs.
Il y a des namespaces implicites. Par exemple si tu as une classe "Foo" dans un framework "FrameWork" et dans une application "Bar", alors le nom complet de ces classes est respectivement "FrameWork.Foo" et "Bar.Foo".
- Introspection with Swift - Spoiler : Swift n'a actuellement pas grand chose dans ce domaine, et ce qui existe n'est même pas forcément prévu pour faire partie d'APIs...
Edit : les devs Apple sont marqués du logo d'Apple à gauche sur leur avatar, il y a gparker qui répond beaucoup à ce type de questions, Chris Lattner n'est pas bavard, mmalc, jckarter, quelques autres... Bref, c'est intéressant d'avoir des infos directes.
Personne n'a parlé du pattern matching des swicth ? Je trouve pourtant ça intéressant, et ça ressemble à ce qu'on peut trouver dans ocaml.
Oui le Pattern Matching est très puissant, les switch dans Swift (tournez 3x votre langue dans votre bouche avant de dire ça ) va beaucoup plus loin que des switch classiques qu'on connait. Faire des switch sur des ranges, faire des where, tout ça, c'est une tuerie !!
L'inférence des types aussi est intéressante pour les variables/constantes locales.
Oui c'est intéressant pour un peu tout même je trouve, entre autres pour les variables/constantes qui contiennent des blocs (closures), donc la syntaxe serait lourde à répéter. Exemple en Objective-C :
let block = { (count: int, string: String, capitalize: BOOL, joiner: String) in
...code...
return 1 // int inféré
}
Pas besoin de répéter le type du block et de faire un peu de redite comme en ObjC (alors que la syntaxe est déjà lourde en ObjC), c'est bien plus compact !
Et surtout que ceux qui découvrent Swift ne s'y trompent pas (j'ai déjà vu plusieurs fois l'erreur de compréhension), Swift n'est PAS un langage à typage faible. Au contraire, Swift EST un langage à typage FORT. Il est juste capable d'inférer un type, mais une fois ce type inféré, il est associé de façon permanente à la variable. Si on déclare var a = "Hello" alors la variable a va être inférée comme étant de type String, et va le rester donc même si on n'a pas explicitement spécifié le type de la variable a, il est impossible d'écrire "a = 7" à la ligne d'après, car la variable 'a' est de type String et pas de type Int. Donc ce n'est pas un typage faible mais bien un typage fort, juste inféré quand c'est possible.
La syntaxe d'indication des types ressemble à se qu'on trouve dans les langages ml. (Dans les langages ML une fonction qui prend 2 entiers et renvoi 1 chaine de caractère possède ce type, Int -> Int -> String, c'est très pratique pour faire de la curryfication, composition, renvoyer des fonctions etc...)
A noter que la curryfication est aussi supportée en Swift (même si c'est pas forcément mis en avant, c'est un peu caché dans la doc) !! Bon pour ceux qui débutent en Swift ça peut perturber car on commence déjà à parler de "fonction qui retourne une fonction" avec la curryfication, mais bon c'est quand même très puissant :
Ce code de multiplierFunction utilise la syntaxe de curryfication pour décrire une fonction qui prend un Int (factor) et retourne en sortie... une autre fonction de type Int->Int. On pourrait l'écrire de façon stricte comme une fonction de type "Int->(Int->Int)" (fonction qui prend un int et retourne un Int->Int)... et déclarer une fonction interne au scope de la fonction multiplierFunction qui capture multiplier et est retournée en résultat... mais bon ça ferait une syntaxe beaucoup plus lourd, alors que là avec la curryfication c'est bien plus léger à écrire.
Bon on n'utilisera pas ça tous les jours (tout le monde n'écrit pas des fonctions retournant des fonctions ) mais ça montre la puissance de ce langage !
En faite je trouve que Swift se rapproche syntaxiquement d'un langage fonctionnel.
C'est à mon avis un peu le but quand ils ont construit le langage
* Ajouter les namespaces (J'ai vu dans la doc la notion de module, mais j'ai pas trop compris)
C'est déjà fait, les namespaces sont implicites par le scope des classes & co. Tu spécifies un enum par son nom complet avec nomDeLEnum.nomDeLaValeur. Plus besoin d'enums aux valeurs à ralonge genre NSTextAlignmentRight. On a un enum dont le nom est NSTextAlignment, et ses valeurs sont .Left, .Center et .Right quand on utilise la syntaxe courte (parce que le nom complet peut être inféré, par exemple parce qu'on l'affecte à une propriété qui est de type NSTextAligment), ou si on veut ou doit utiliser la syntaxe longue, ces valeurs d'enum sont NSTextAligment.Left, NSTextAlignment.Center, NSTextAlignment.Right donc préfixés par le "namespace" "NSTextAlignment."
De même toutes les classes qui sont déclarées en Swift dans ton application ou dans ton Target sont implicitement dans le module / le namespace de ton application. Tant que tu es dans le code de ton application et qu'il peut donc deviner le namespace (puisqu'il est déjà dans un namespace commun) pas besoin de préciser ce namespace. Mais si tu fais un framework et le distribue ensuite, les gens pourront faire référence aux classes de ton framework avec TonFramework.LaClasse pour les différencier si besoin d'une autre classe LaClasse qu'ils auraient eux aussi dans leur app avec le même nom.
* Ajouter la visibilité private, public, protected (apparemment c'est prévu pour une prochaine version)
C'est déjà prévu dès la prochaine Seed, confirmé par Chris Lattner sur les forums Apple officiels, ils n'ont juste pas eu le temps de l'intégrer à cette seed de LLVM.
* Et garder les exceptions avec try catch. Là on ne peux plus gérer les exceptions et je trouve ça dommage. Même si ce n'était pas très utiliser en objective-c, c'est quelque chose d'extrêmement pratique pour remonter les erreurs.
C'est pas faux, je n'ai pas exploré cette question encore. Mais je pense que c'est faisable (si le langage ne le permet pas encore, je pense qu'il le permettra dans un proche futur, un peu comme les access modifiers public/private/etc qui sont déjà prévus.
Il ne faut pas oublier que Swift, même si son développement a démarré il y a déjà 4 ans dans le plus grand secret (j'en suis encore sur le c*l que rien n'ait fuité !), reste un langage très jeune. Apple a rappelé à plusieurs reprises dans ses vidéos que d'une part ils sont preneurs de retours pour améliorer le langage, et d'autre part le langage est garanti d'évoluer un peu d'ici à la sortie officielle.
Ne commencez pas forcément à recoder toutes vos applis en Swift, Swift n'est pas encore totalement prêt pour une appli en production. On peut faire mumuse avec, mais il va évoluer vite dans les prochains moins en fonction des retours nombreux des devs (donc les retours déjà faits à la WWDC en direct), donc ça a le temps de bcp changer d'ici septembre/octobre pour ajouter tous ces trucs manquants.
en KVO on a ce qu'il faut avec "willSet" et "didSet" qu'on peut mettre sur les propriétés. A mon sens c'est amplement suffisant (j'ai jamais été fan de KVO en transverse. En interne dans une classe pourquoi pas, mais demander à une classe A d'observer une classe B et de faire des choses si B.x change, je suis pas fan car ça peut avoir des conséquences qui vont au delà de ce qu'on imagine, en changeant B.x on n'a pas conscience que ça déclenche tout un code, potentiellement long et complexe, dans la classe A...)
Private/Public/Protected j'ai déjà confirmé moi aussi. Note pour revenir à la remarque de noliv que iOS8 n'est PAS sous NDA cette année, contrairement aux années précédentes. Donc on peut en parler. (Par contre ce qui est dit sur les forums officiels Apple réservés aux personnes avec un compte dev, là j'ai un doute)
Dommage pour l'introspection, c'est plutôt pratique pour faire des librairies un peu dynamique. Quand je parlé d'introspection je parlé aussi d'appel dynamique, je retente mais je pense que la réponse est non. Est-ce possible d'appeler une méthode à partir d'une string par exemple ?
Ca dépend ce que tu appelles introspection. Mais vu ce que tu sembles mettre derrière, oui tu peux tout à fait :
Représenter l'objet Class (pour le mettre dans une variable d'un type équivalent à ce qu'on a avec "Class" en ObjC) : NSString.self par exemple représente la classe NSString elle-même, équivalent de [NSString class] en ObjC.
savoir de quel type est déclaré une variable, et même récupérer ce type dans une variable avec ".Type". Par exemple si tu déclares "var x: Vehicle" alors "x.Type" va te retourner la classe Vehicle (Vehicle.self)
savoir de quel type est réellement une variable au Runtime et récupérer ce type dans une variable avec ".dynamicType". Par exemple si tu écris après l'exemple précédent "x = Car()" (où Car est une sous-classe de Vehicle) alors x.Type vaudra toujours Vehicle.self car c'est le type déclaré pour la variable, mais x.dynamicType vaudra Car.self
Si tu veux appeler une méthode de classe sur une classe, bah tu fais comme en ObjC. "NSUserDefaults.standardUserDefaults()" va appeler la méthode de classe "standardUserDefaults" de la classe NSUserDefaults. Tu peux même avoir des variables/propriétés/constantes de classe (chose qu'on n'a pas en ObjC)
Bref y'a de quoi faire de l'introspection au sens où tu l'entends.
Ah, ok. Ca ça n'est pas vraiment de l'introspection mais du KVC.
On peut faire de l'introspection en testant si un objet répond à une méthode (par exemple tester si on objet qui se trouve être un UITableViewDelegate répond au @selector(tableView:didSelectRowAtIndexPath:) c'est très simple en Swift, et c'est même + puissant puisqu'on peut tester et appeler en même temps avec le Optional Chaining, plus besoin de faire "if (respondsToSelector:xx) { xx(parametres) }" donc.
Par contre Swift ne permet pas (encore?) de faire du KVC en appellant une méthode d'après son nom qu'on aurait sous forme de String. Je sais pas si c'est prévu dans le futur proche ou pas. C'est pas dit, car ça casse un peu le côté "Safe" du langage, en même temps.
Oui pour iOS7 c'est un peu tard... du coup je sais pas cmt ils vont faire.
Genre embarquer la lib statique du Runtime Swift dans toutes les applications qui ont été compilées avec du Swift et ont un Target < iOS8, et ne pas l'intégrer si le Deployment Target est 8 ou supérieur, peut-être ?
Réponses
1. On met les parenthèses vides en entrée et en sortie puisque le type représentant une fonction c'est "(ParamsEnEntrée)->(ParamsEnSortie)" et qu'ici il n'y a ni params d'entrée ni de sortie. Tu voudrais mettre "->()" sans les "()" devant ? ou "()->" sans les "()" derrière ?! Ca serait un peu bizarre...
Le type Swift "()->()" est exactement comme le type Objective-C "void(^)(void)".
Mais si tu préfères tu peux aussi utiliser "Void" à la place de "()" pour représenter une liste vide de paramètres. Ca te semblera peut-être plus lisible ?
func times(task: Void->Void) { ...implementation... }2. Avec le mot clé "func" tu déclares une fonction, avec son nom et son corps. Donc "func" va en début de ligne ou démarrer une déclaration, exactement comme les mots clés "class" ou "struct". Le mot clé "func" ne serait donc pas à sa place à l'intérieur de paramètres d'une fonction.Si le paramètre "task" était un "Int" et pas une fonction, tu ne mettrais pas "var task: Int", (car "var" est fait pour déclarer une variable) donc là y'a pas de raisons de mettre "func task: Void->Void" (car "func" est fait pour déclarer une fonction). Dans tes paramètres tu ne mets que "nom: Type", donc là c'est pas "x: Int" c'est "task: Void->Void", c'est pareil. Faut pas chercher plus compliqué, la syntaxe est consistante.
Sinon, en Swift les fonctions et les closures ont le même types. On peut voir "func" comme un mot clé servant juste à "donner un nom constant à une closure".
Ainsi, on peut voir ces 3 lignes comme équivalentes :
Dans tous les cas, le type de "toto" est "(Int)->Double", autrement dit "un fonction ou closure qui prend un Int et retourne un Double". Une fois déclaré, Swift ne fait plus la différence que ce soit une fonction ou une closure (enfin en interne peut-être, si, j'en sais rien, mais en tout cas en pratique ils sont totalement interchangeables)
Question bête, y'aura moyen de porter ses app sur PC, car j'aimerais faire des bon gros projets avec ça sinon je reste sur mon C++ adoré ^^
On change de langage, pas de framework hein (encore heureux!)
Si si t'y a même répondu.
Là , tu marques un point.
J'ai jamais autant entendu parler des closures que depuis la sortie de Swift... Quelle en est la raison ?
Plus sérieusement tout simplement parce qu'avant Swift on avait déjà les closures (en Ruby, en JavaScript, en Objective-C...) mais on ne les utilisait pas forcément à leur pleine puissance... ou alors on ne les appelait pas comme ça tout simplement.
Et parce que ce qu'on appelait "block" en Objective-C on l'appelle "closure" en Swift (alors que les blocks en ObjC étaient des closures)
Avec Swift d'une part toute fonction n'est rien d'autre qu'une closure qui a un nom (constant) associé, mais en plus avec la syntaxe des "training closures" (la même que celle que tu connais en Ruby mais qu'on avait pas en ObjC) ça rend les closures vachement + sexy.
tab.map { 2*$0 } // comme un block en RubyLes closures de Swift c'est le combiné de ce qu'on trouve en Ruby avec les blocks + les Proc + les lambda + les fonctions + les opérateurs... c'est un type unique pour les gouverner tous ^^tab.filter { $0>0 } // pareil
tab.map(uppercaseString) // en Ruby on passerait un Proc via "&:uppercaseString"
tab.map(-) // je sais même pas si on peut faire ça en Ruby!
Plus sérieusement ça ouvre des perspectives avec de nouvelles fonctions sympas qu'on avait pas en ObjC du coup ils en sont fiers ;-)
Ce qui me semble important n'est pas tant le langage (tant que c'est de la POO, aucun problème) mais les "classes mères" que l'on dérive pour construire son logiciel. Celles de Cocoa pour l'interface graphique sont nombreuses et puissantes, simples et souples d'emploi. En sera t-il de même pour Swift? A moins que l'on ne puisse utiliser les mêmes... (Il faudra que je lise la doc à ce sujet, pour l'instant je galère avec Core Audio/iOS...)
D'ici quelques années les API seront en Swift. Je me suis accroché au Pascal (+objets) aussi longtemps que j'ai pu et j'ai raté le passage sur Objective-C de plusieurs années. Pas question de refaire la même erreur.
Cela dit, j'ai eu un petit sursaut de nostalgie en découvrant le mot-clé override...
Pour l'instant, je découvre le playgroud et aligne les erreurs...
D'ailleurs ils le montrent dans à peu près toutes les démos. Genre les démos où on voit Playground dans lequel ils font des animations CoreAnimation et font bouger des sorites SpriteKit & co
Toutes les méthodes sont traduites à la volée.
En parlant de syntaxe, je me suis retrouvé avec quelque chose qui m'a paru bizarre. Dans la fonction touchBegan j'ai écrit ceci :
Le "as UITouch" ("as" que je retrouve assez souvent) me fait un peu bizarre et me parait beaucoup moins claire que "[[event allTouches] anyObject]"... M'y suis-je mal prit ? Qu'en pensez-vous ?
Sauf qu'en ObjC, anyObject retourne un "id". Donc un truc "on sait pas trop ce que c'est".
Alors qu'en Swift, les tableaux sont typés avec le type de leur élément. On a String[] (ou Array<String>) pour un tableau de String, Int[] (ou Array<Int>) pour un tableau d'entiers, etc.
Là vu que le code ObjectiveC de [[event allTouches] anyObject] retourne un id, en Swift ça se traduit par un "AnyObject[]!" (l'équivalent d'un tableau de "id" si tu veux). Le cast doit alors être explicite pour pouvoir ensuite utiliser touch comme un objet UITouch.
Je pense (j'ai pas testé) que tu pourrais laisser Swift inférer le type de ta variable "touch"Et il devrait pouvoir deviner que ta variable devra être de type UITouch. Par contre ça ne m'étonnerai pas que tu ne puisses pas faire l'inverse (forcer le type de ta variable "let touch: UITouch" mais ne pas faire le casting "as UITouch") car un cast de AnyObject vers autre chose (ici un UITouch) doit être explicite, surtout qu'il peut échouer (si jamais y'a un problème et que ton tableau event.allTouches() contient des objets autres que des UITouch et qui ne peuvent pas être convertis en UITouch).
Voici une FAQ intéressante (en anglais): http://www.raywenderlich.com/74138/swift-language-faq
Il semble que dans le futur ils vont utiliser Swift dans leurs articles et tutoriels.
Swift infère le type sans problème dans cet exemple (grâce au "as" qui correspond à un cast en C/C++/Objc).
Par contre je ne pense pas qu'il vérifie la compatibilité des types (faut que je relise la doc...), car pour cela il existe un opérateur de "downcast" "as?", qui va vérifier que l'objet casté est bien compatible avec le type demandé. Cela n'a pas d'équivalent en ObjC et correspond au "dynamic_downcast<T>" de C++.
Dans mon exemple, j'utilise "as?" (ce qui n'a aucun intérêt ici, mais c'est pour l'exemple). Le résultat étant optionnel, il faudra passer par une phase d'unwrapping pour utiliser l'objet. J'utilise l'optionnal binding pour créer une nouvelle constante aTouch en unwrappant la constante optionnelle touch. On n'entre dans le if que si la constante touch avait une valeur.
Personne n'a parlé du pattern matching des swicth ?
Je trouve pourtant ça intéressant, et ça ressemble à ce qu'on peut trouver dans ocaml.
L'inférence des types aussi est intéressante pour les variables/constantes locales.
La syntaxe d'indication des types ressemble à se qu'on trouve dans les langages ml.
(Dans les langages ML une fonction qui prend 2 entiers et renvoi 1 chaine de caractère possède ce type, Int -> Int -> String, c'est très pratique pour faire de la curryfication, composition, renvoyer des fonctions etc...)
En faite je trouve que Swift se rapproche syntaxiquement d'un langage fonctionnel.
Je trouve que l'utilisation de tuple de valeur est top (pour le retour multiple par exemple). Surtout qu'on peut avoir des tuples nommé, et statiquement typés !
Par contre, quitte à faite un nouveau langage ils auraient pu:
* Ajouter les namespaces (J'ai vu dans la doc la notion de module, mais j'ai pas trop compris)
* Ajouter la visibilité private, public, protected (apparemment c'est prévu pour une prochaine version)
* Et garder les exceptions avec try catch. Là on ne peux plus gérer les exceptions et je trouve ça dommage. Même si ce n'était pas très utiliser en objective-c, c'est quelque chose d'extrêmement pratique pour remonter les erreurs.
Il y a des namespaces implicites. Par exemple si tu as une classe "Foo" dans un framework "FrameWork" et dans une application "Bar", alors le nom complet de ces classes est respectivement "FrameWork.Foo" et "Bar.Foo".
Et en passant par là , comment marchera KVO et KVC dans swift ?
Parce que même si KVO et KVC sont des ajouts du framework, les properties synthétisés automatiquement prennent directement en charge KVO et KVC.
Comment faudra-t-il géré cela en Swift ?
Si on veut utilisé de l'introspection, ou appelé dynamiquement une méthode comment faire ?
Sur ce point, il parait que* les devs d'Apple disent clairement sur les forums officiels que c'est prévu, que ça va venir.
* il parait que j'en suis sûr mais qu'avec les NDA, tout ça...
Pour ceux qui ont accès aux forums officiels d'Apple et qui blablatent en anglais, ces sujets sont discutés :
- KVO on Swift classes that do not inherit from NSObject - Spoiler : Il n'y a actuellement pas d'équivalent en Swift
- Private, Protected, Public with Swift - Spoiler : Swift aura ces mécanismes, pour l'instant ils manquent à l'appel
- Introspection with Swift - Spoiler : Swift n'a actuellement pas grand chose dans ce domaine, et ce qui existe n'est même pas forcément prévu pour faire partie d'APIs...
Edit : les devs Apple sont marqués du logo d'Apple à gauche sur leur avatar, il y a gparker qui répond beaucoup à ce type de questions, Chris Lattner n'est pas bavard, mmalc, jckarter, quelques autres... Bref, c'est intéressant d'avoir des infos directes.
Dommage pour l'introspection, c'est plutôt pratique pour faire des librairies un peu dynamique.
Quand je parlé d'introspection je parlé aussi d'appel dynamique, je retente mais je pense que la réponse est non.
Est-ce possible d'appeler une méthode à partir d'une string par exemple ?
Oui c'est intéressant pour un peu tout même je trouve, entre autres pour les variables/constantes qui contiennent des blocs (closures), donc la syntaxe serait lourde à répéter. Exemple en Objective-C :
int (^block)(int, NSString*, BOOL, NSString*) = int^(int count, NSString* string, BOOL capitalize, NSString* joiner) {Plutôt lourd, non ? Alors qu'en Swift :...code...
return 1;
}
let block = { (count: int, string: String, capitalize: BOOL, joiner: String) inPas besoin de répéter le type du block et de faire un peu de redite comme en ObjC (alors que la syntaxe est déjà lourde en ObjC), c'est bien plus compact !...code...
return 1 // int inféré
}
Et surtout que ceux qui découvrent Swift ne s'y trompent pas (j'ai déjà vu plusieurs fois l'erreur de compréhension), Swift n'est PAS un langage à typage faible. Au contraire, Swift EST un langage à typage FORT. Il est juste capable d'inférer un type, mais une fois ce type inféré, il est associé de façon permanente à la variable. Si on déclare var a = "Hello" alors la variable a va être inférée comme étant de type String, et va le rester donc même si on n'a pas explicitement spécifié le type de la variable a, il est impossible d'écrire "a = 7" à la ligne d'après, car la variable 'a' est de type String et pas de type Int. Donc ce n'est pas un typage faible mais bien un typage fort, juste inféré quand c'est possible.
A noter que la curryfication est aussi supportée en Swift (même si c'est pas forcément mis en avant, c'est un peu caché dans la doc) !! Bon pour ceux qui débutent en Swift ça peut perturber car on commence déjà à parler de "fonction qui retourne une fonction" avec la curryfication, mais bon c'est quand même très puissant :
func multiplierFunction(factor: Int)(x: Int)->Int {
Ce code de multiplierFunction utilise la syntaxe de curryfication pour décrire une fonction qui prend un Int (factor) et retourne en sortie... une autre fonction de type Int->Int. On pourrait l'écrire de façon stricte comme une fonction de type "Int->(Int->Int)" (fonction qui prend un int et retourne un Int->Int)... et déclarer une fonction interne au scope de la fonction multiplierFunction qui capture multiplier et est retournée en résultat... mais bon ça ferait une syntaxe beaucoup plus lourd, alors que là avec la curryfication c'est bien plus léger à écrire.return { x in factor*x }
}
doubler = multiplierFunction(2)
tripler = multiplierFunction(3)
doubler(3) // 6
doubler(7) // 14
tripler(11) // 33
Bon on n'utilisera pas ça tous les jours (tout le monde n'écrit pas des fonctions retournant des fonctions
C'est à mon avis un peu le but quand ils ont construit le langage
De même toutes les classes qui sont déclarées en Swift dans ton application ou dans ton Target sont implicitement dans le module / le namespace de ton application. Tant que tu es dans le code de ton application et qu'il peut donc deviner le namespace (puisqu'il est déjà dans un namespace commun) pas besoin de préciser ce namespace. Mais si tu fais un framework et le distribue ensuite, les gens pourront faire référence aux classes de ton framework avec TonFramework.LaClasse pour les différencier si besoin d'une autre classe LaClasse qu'ils auraient eux aussi dans leur app avec le même nom.
C'est déjà prévu dès la prochaine Seed, confirmé par Chris Lattner sur les forums Apple officiels, ils n'ont juste pas eu le temps de l'intégrer à cette seed de LLVM.
C'est pas faux, je n'ai pas exploré cette question encore. Mais je pense que c'est faisable (si le langage ne le permet pas encore, je pense qu'il le permettra dans un proche futur, un peu comme les access modifiers public/private/etc qui sont déjà prévus.
Il ne faut pas oublier que Swift, même si son développement a démarré il y a déjà 4 ans dans le plus grand secret (j'en suis encore sur le c*l que rien n'ait fuité !), reste un langage très jeune. Apple a rappelé à plusieurs reprises dans ses vidéos que d'une part ils sont preneurs de retours pour améliorer le langage, et d'autre part le langage est garanti d'évoluer un peu d'ici à la sortie officielle.
Ne commencez pas forcément à recoder toutes vos applis en Swift, Swift n'est pas encore totalement prêt pour une appli en production. On peut faire mumuse avec, mais il va évoluer vite dans les prochains moins en fonction des retours nombreux des devs (donc les retours déjà faits à la WWDC en direct), donc ça a le temps de bcp changer d'ici septembre/octobre pour ajouter tous ces trucs manquants.
- en KVO on a ce qu'il faut avec "willSet" et "didSet" qu'on peut mettre sur les propriétés. A mon sens c'est amplement suffisant (j'ai jamais été fan de KVO en transverse. En interne dans une classe pourquoi pas, mais demander à une classe A d'observer une classe B et de faire des choses si B.x change, je suis pas fan car ça peut avoir des conséquences qui vont au delà de ce qu'on imagine, en changeant B.x on n'a pas conscience que ça déclenche tout un code, potentiellement long et complexe, dans la classe A...)
- Private/Public/Protected j'ai déjà confirmé moi aussi. Note pour revenir à la remarque de noliv que iOS8 n'est PAS sous NDA cette année, contrairement aux années précédentes. Donc on peut en parler. (Par contre ce qui est dit sur les forums officiels Apple réservés aux personnes avec un compte dev, là j'ai un doute)
Ca dépend ce que tu appelles introspection. Mais vu ce que tu sembles mettre derrière, oui tu peux tout à fait :- Représenter l'objet Class (pour le mettre dans une variable d'un type équivalent à ce qu'on a avec "Class" en ObjC) : NSString.self par exemple représente la classe NSString elle-même, équivalent de [NSString class] en ObjC.
- savoir de quel type est déclaré une variable, et même récupérer ce type dans une variable avec ".Type". Par exemple si tu déclares "var x: Vehicle" alors "x.Type" va te retourner la classe Vehicle (Vehicle.self)
- savoir de quel type est réellement une variable au Runtime et récupérer ce type dans une variable avec ".dynamicType". Par exemple si tu écris après l'exemple précédent "x = Car()" (où Car est une sous-classe de Vehicle) alors x.Type vaudra toujours Vehicle.self car c'est le type déclaré pour la variable, mais x.dynamicType vaudra Car.self
- Si tu veux appeler une méthode de classe sur une classe, bah tu fais comme en ObjC. "NSUserDefaults.standardUserDefaults()" va appeler la méthode de classe "standardUserDefaults" de la classe NSUserDefaults. Tu peux même avoir des variables/propriétés/constantes de classe (chose qu'on n'a pas en ObjC)
Bref y'a de quoi faire de l'introspection au sens où tu l'entends.Intéressant tes réponses Ali.
Mais je pense que je me suis mal fait comprendre sur le sens que je donnais à Introspection.
Mais la question qui m'intéressais le plus était surtout de savoir si je peux appelé une méthode sur un objet à partir d'une string quelconque.
Par exemple en ObjC je peux faire ça:
On peut faire de l'introspection en testant si un objet répond à une méthode (par exemple tester si on objet qui se trouve être un UITableViewDelegate répond au @selector(tableView:didSelectRowAtIndexPath:) c'est très simple en Swift, et c'est même + puissant puisqu'on peut tester et appeler en même temps avec le Optional Chaining, plus besoin de faire "if (respondsToSelector:xx) { xx(parametres) }" donc.
Par contre Swift ne permet pas (encore?) de faire du KVC en appellant une méthode d'après son nom qu'on aurait sous forme de String. Je sais pas si c'est prévu dans le futur proche ou pas. C'est pas dit, car ça casse un peu le côté "Safe" du langage, en même temps.
Je rêve ou libswift_stdlib_core rajoute 2.3 M à la plus petite des applications? J'ai loupé un paramètre dans la construction du projet?
Sauf sur iOS 7, non ?
D'autant que les framework sont maintenant autorisés sur iOS 8.
Genre embarquer la lib statique du Runtime Swift dans toutes les applications qui ont été compilées avec du Swift et ont un Target < iOS8, et ne pas l'intégrer si le Deployment Target est 8 ou supérieur, peut-être ?
C'est chaud ça.
Donc si notre app est compatible iOS 7 et iOS 8, ça serait sûrement plutôt iOS 7.2 min... (si ça inclut Swift)