Swift et immutabilite

Paisible.fr

Bonjour,

 

Je viens de tomber sur ce tweet : https://twitter.com/dwarfland/status/476310789763395584/photo/1

Apparement le comportement de Swift peut être un peu innatendu parfois...

 

PS : je precise que je n'ai pas encore eu l'occasion de verifier dans un playground.

Paisible.fr

Visiblement il semblerait que ce comportement soit clairement mentionne dans la documentation de Swift.

Je pense que dans les premier temps on peut facilement se laisser pieger.

AliGator

Oui je suis assez d'accord. Les règles de mutabilité sur les tableaux sont bien documentées (un tableau est mutated que quand on change son nombre d'éléments et pas quand on change un élément dans le tableau sans changer sa longueur) il n'empêche que c'est un comportement à  l'opposé de la logique et de la cohérence. J'ai pas compris pourquoi ils avaient établi ces règles bizarres pour les tableaux...

Paisible.fr

@AliGator:

• Effectivement, je ne comprends pas pourquoi ils ont etablis ces regles. Peut être qu'un jour on aura une explication sur les raisons derriere ce choix. Sait on jamais...
• Il est certain qu'au debut on ne va pas manquer de ce faire avoir une fois ou deux. Le temps que cela rentre bien dans les esprits ::)

Paisible.fr

[Hors sujet] J'avais mis en page mon texte avec une liste numerotee (<ul><ol>) a l'aide de l'editeur. Visiblement il n'en a pas tenu compte.

AliGator

[Hors sujet] J'avais mis en page mon texte avec une liste numerotee (<ul><ol>) a l'aide de l'editeur. Visiblement il n'en a pas tenu compte.

Petit bug du forum je viens de rétablir.

jojolebg

C'est vrai que c'est bizarre.

Surtout que c'est tellement utile de travailler avec des tableaux et dictionnaires immutable (dans le sens non modifiable du tout).


ça permet souvent d'augmenté l'abstraction du code. Par exemple en objective C on se voit mal mettre une property publique lecture/écriture en NSMutableArray ou NSMutableDictionary, car cela signifierait que de l'extérieur on puisse modifier mon tableau.


On peut se dire qu'il suffit de mettre la property en lecture seul, mais ça ne change pas le problème, si la property est un NSMutableArray, le tableau sera modifiable.


Donc si on ne veut pas que nos tableaux soit directement modifier de l'exterieur (car on préfère que de l'extérieur on passe par l'abstraction fourni par notre classe), on doit mettre la property en NSArray lecture seul. (Quoi que en bidouillant, si le vrai type est NSMutableArray il serait possible de rajouter des éléments au tableau).


Mais une façons de procédé que je trouve plutôt sympa et sécurisé (surtout dans des contextes multi-thread), c'est d'utilisé des property en NSArray, et dans notre code si on veux ajouté un élément à  notre tableau on fera

 

self.myArray = [[self.myArray mutableCopy] add:myObj];

// au lieu de

[self.myArray add:myObj];

Certes c'est plus verbeux, mais beaucoup plus sécurisé. Et cela suffit dans la plupart des cas.

Pyroh

Je ne pense pas qu'il faille voir l'immutabilité proposée par swift comme une sécurité mais comme une optimisation.

 

Utiliser let plutôt que var est la certitude qu'on va accéder plus vite à  une ressource mais aussi que la valeur ne sera pas entourée de toute une machinerie lui permettant d'être modifiée et déplacée en mémoire à  chaque modification. 

Pour les Array l'espace mémoire est allouée une bonne fois pour toute, une adresse de pointeur ayant une taille strictement invariable (Apple utilise surement des pointeurs dans les Array. Je les vois mal gérer différemment les scalars et les objects au sein d'un Array).

 

C'est étonnant de prime abord. Si on y réfléchi c'est plus ou moins logique si on se place du point de vue de l'optimisation, pas du point de vue de la sécurité.

La sécurité n'est pas nécessairement fournie par le langage mais par le designer d'API, on a tendance à  l'oublier. (oui, si le langage file un coup de main c'est bonnard mais on chipote...)

AliGator

Pour les Array l'espace mémoire est allouée une bonne fois pour toute, une adresse de pointeur ayant une taille strictement invariable (Apple utilise surement des pointeurs dans les Array. Je les vois mal gérer différemment les scalars et les objects au sein d'un Array).

C'est ce qu'on peut penser de prime abord, mais les NSArray d'ObjC par exemple sont particulièrement optimisés, au point que leur stockage interne dépend du nombre d'éléments qu'ils contiennent. Ca peut en interne être géré par un tableau à  taille fixe comme en C, ou autrement, par exemple une liste doublement chaà®née indexée (liste chaà®née qui permet d'aller dans les 2 sens et dont on a un pointeur direct sur les éléments multiples de N, pour pouvoir sauter directement à  l'élément N puis parcourir ses alentours quand on a besoin d'aller chercher loin dans le tableau) qui permet une optimisation de la mémoire utilisée, du redimentionnement et d'opérations comme l'ajout ou suppression d'un élément, etc...

Je te redirige vers cet article de RidiculousFish pour plus d'infos (il date mais il est toujours d'actualité, après tout l'auteur du blog est un mec de chez Apple qui bosse sur AppKit)

samir

Pour information, Ils ont redesigné la classe Array en béta 3 pour ce comporter comme les dictionnaires. C'est dans la béta 3.

AliGator

Alléluia !


Et les public/private/protected c'est enfin de la partie aussi ou faudra encore attendre la prochaine ?

Pas encore eu le temps de regarder le changelog

samir

Et les public/private/protected c'est enfin de la partie aussi ou faudra encore attendre la prochaine ?

 

Non pas inclus, il faut attendre

muqaddar

Maintenant:

 

var array est mutable.

let array est immutable.

Joanna Carter

Hourra !