« Constant and variable names cannot contain mathematical symbols, arrows, private-use (or invalid) Unicode code points, or line- and box-drawing characters. Nor can they begin with a number, although numbers may be included elsewhere within the name. »et cf. la grammaire ici.
Extrait de: Apple Inc. « The Swift Programming Language. » iBooks. https://itun.es/fr/jEUH0.l
Uther (./185) :
Je vois pas ce que ça a d’exceptionnel, Il y a déjà plusieurs langages capable de ça notamment Java qui permet ça depuis toujours.
Un exemple en Rust: https://gist.github.com/anonymous/93a62904346c1d5718d7
Brunni (./189) :Ça pourrait faire un bon nom pour un jeu ou pour un groupe de musique, ça
Moderu Miharashi Contorora
Brunni (./189) :
En l'occurrence c'est plutôt crade comme truc si on veut être objectif, mais perso j'aime autant que ce soit supporté (au final à toi d'en faire bon usage).
Folco (./193) :Non je crois que t'as pas compris, c'est Apple donc faut à tout prix trouver un justificatif qui prouve qu'ils ont repompé la fonction d'ailleurs, même si en fait c'est pas vrai et qu'en plus c'est une fonction anecdotique…
N'est-ce pas ? Enfin, c'est apple, donc c'est bien, même si c'est nul à chier
Franchement, ya d'autres moyens de vanter le langage, non ?Ben justement, je crois que le but n'était pas de "vanter" le langage dans ce qui a été discuté à ce sujet (là où ailleurs). Mais c'est pourtant ce que tu en retiens, étrange, n'est-ce pas ?
L'inférence de type par exemple, il m'a fallu quelque temps pour comprendre qu'en cas de refactoring/réutilisation, ça pouvait faire gagner beaucoup de temps. Une bonne compensation à un côté non-safe qu'on peut craindre au premier abord.Ouais enfin c'est pas le but initial de l'inférence de type. C'est surtout que ça simplifie énormément l'écriture du code, et ça réduit la densité d'informations en supprimant une information redondante. (i.e. qui est parfaitement déductible par d'autres moyens, soit algorithmiques, soit intellectuels. Donc totalement "safe" d'ailleurs.)
HashMap<String, String> map = new HashMap<String, String>(); MyClass<Fucking, Genericity<Of<Doom>, T> var = getMyClass(); MyClass<Fucking, Genericity<Of<Doom>, T> copyOfVar = (MyClass<Fucking, Genericity<Of<Doom>, T>) var.clone();
Brunni (./195) :
Folco> L'inférence me faisait aussi peur jusqu'à ce que je fasse du Java "compliqué" et que je commence à me rendre compte que :HashMap<String, String> map = new HashMap<String, String>(); MyClass<Fucking, Genericity<Of<Doom>, T> var = result(); MyClass<Fucking, Genericity<Of<Doom>, T> copyOfVar = (MyClass<Fucking, Genericity<Of<Doom>, T>) var.clone();
C'était vraiment redondant et n'apportait pas grand chose ^^
HashMap<Object, Object> map = new HashMap<Object, Object>(); MyClass<Object, Object, Object> var = result(); MyClass<Object, Object, Object> copyOfVar = (MyClass<Object, Object, Object>) var.clone();
GarbageCollector> Ouais pourtant c'est le cas, c'est limité aux alphabets proches de chez nous.En fait pour être plus exact ça m'étonne parce qu'il me semblait que le Java se basait sur les catégories Unicode comme le C# pour valider ses identificateurs… Faut que je trouve une définition valide de la syntaxe de Java pour vérifier
GoldenCrystal (./194) :
Ben justement, je crois que le but n'était pas de "vanter" le langage dans ce qui a été discuté à ce sujet (là où ailleurs). Mais c'est pourtant ce que tu en retiens, étrange, n'est-ce pas ?
flanker (./196) :
Quel est le côté non-sûr de l'inférence de type ?
Brunni (./195) :
L'inférence me faisait aussi peur jusqu'à ce que je fasse du Java "compliqué" et que je commence à me rendre compte que :
Brunni (./195) :
C'était vraiment redondant et n'apportait pas grand chose ^^
Folco (./200) :flanker (./196) :
Quel est le côté non-sûr de l'inférence de type ?
T'as fait de l'assembleur aussi, non ? Mais il y a longtemps, alors t'as dû oublier : tout bit de ton programme que tu ne fais pas toi-même fait peur, quand tu ne fais quasiment que de l'asm. L'inférence de type rajoutant encore une couche d'automatisation à un langage typé (ce qui était rassurant à la base, donc là tu comprends plus trop), tu as peur avant d'avoir compris, forcément. C'est juste humain.
Folco (./200) :Là où je veux en venir c'est pas parce que quelqu'un note un "détail intéressant" qu'il vante quoi que ce soit. Et qu'en revanche on en a vu ici "anti-vanter" pas mal, si tu vois où je veux en venir
Ben ce qui m'intéresse, en-dehors de "on peut faire un programme avec ce nouveau langage de programmation, sisi !", c'est le côté "avantage, nouveauté intéressante que l'on ne trouve pas ailleurs !" qui m'intéresse. C'est un tort ? C'est justement pour ça que je parle de vanter, parce que je pensais, bêtement peut-être ? qu'il serait intéressant de mettre en avant les points... intéressants ? J'espère pas avoir eu tort ><
GoldenCrystal (./203) :
C'est un peu comme tous les français qui confondent expliquer et justifier, je trouve ça assez agaçant
GoldenCrystal (./203) :
si tu vois où je veux en venir
flanker (./202) :
Au final, on fait des templates C++ de façon transparente et naturelle
var a = 128; // a de type int
byte b = 128; // b de type byte
var c = a + b; // c de type int; c = 256
var d = b + b; // d de type int; d = 256
var e = (byte)(b + b); // e de type byte; e = 0
var f = b; // f de type byte; f = 128
Y'a rien de sorcier là dedans, c'est le devoir de tout développeur de base de comprendre ça. Mais tu peux facilement voir le genre de pièges auxquels ça peut silencieusement mener. Tu peux facilement oublier de remettre une valeur dans le bon type, ou même utiliser une valeur du mauvais type (genre float/double avec des entiers, ou double avec float…) et te retrouver avec un résultat qui ne correspond pas du tout à ce que tu voulais obtenir. (Ou des performances qui ne correspondent pas à ce que tu aurais du avoir); Struct Player { u32 x, y, vx, vy; } ORG $CACA MAIN MOVEA.L #obj, A0 ; Ici techniquement A0 est un "var obj" ; Juste qu'on doit savoir ce qu'on fait si on stocke qqch dans le membre "y" (et le compilo moderne le fera pour nous) MOVE.L #0, 4(A0) DEAD BRA DEAD ; Variables - obj: Player obj DS.B 16
« Swift provides signed and unsigned integers in 8, 16, 32, and 64 bit forms. These integers follow a naming convention similar to C, in that an 8-bit unsigned integer is of type UInt8, and a 32-bit signed integer is of type Int32. Like all types in Swift, these integer types have capitalized names. »et
Extrait de: Inc, Apple. « The Swift Programming Language. » Apple Inc., 2014-05-27T07:00:00Z. iBooks.
Ce contenu est peut-être protégé par des droits d’auteur.
Consultez ce livre sur l’iBooks Store : https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewBook?id=881256329
« Swift provides its own versions of all fundamental C and Objective-C types, including Int for integers; Double and Float for floating-point values; Bool for Boolean values; and String for textual data. Swift also provides powerful versions of the two primary collection types, Array and Dictionary, as described in Collection Types. »
Extrait de: Inc, Apple. « The Swift Programming Language. » Apple Inc., 2014-05-27T07:00:00Z. iBooks.
Ce contenu est peut-être protégé par des droits d’auteur.
Consultez ce livre sur l’iBooks Store : https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewBook?id=881256329