Une meÌthode qui renvoie un implicitly unwrapped optional d'après sa signature et qui se retrouve à pouvoir renvoyer nil y'a que moi que ça choque ?
Soit renvoie un optional directement ou mets un assert sur index < self.bigPhotos.count parce que c'est une très mauvaise habitude à prendre. (Un peu de lecture sur le sujet)
Non monsieur. Moi aussi je partage ton indignation. LeChat, ton code corrigé vas cracher si ta méthode doit renvoyer nil.
Une variable de type WPPhotoProtocol! ne peut pas contenir la valeur nil. Ton code doit retourner une WPPhotoProtocol?
En fait, si, un implicitely unwrapped peut contenir nil.
Par exemple, ceci est possible :
import Foundation
class A
{
}
let a:A! = nil
if (a != nil) {
print(a)
} else {
print("a est un \(a.dynamicType) qui est nil")
}
let b:A! = A()
if (b != nil) {
print("b n'est pas nil")
}
Résultat:
"a est un ImplicitlyUnwrappedOptional<A> qui est nil\n"
En fait le "!" veut dire "je te garantis que je ne suis pas nil". Mais c'est surtout un contrat, s'il n'est pas respecté, le programme crash.
En interface avec swift les objects objective-C sont convertis en implicitly unwrapped, mais ils peuvent toujours être nil. Ce n'est pas quelque chose qu'il faut faire en swift pur.
Pas normal ça.. ???
Il se passe quoi quand tu demande un index en dehors des clous ? Tu dois avoir un beau crash, avec ton code qui "fonctionne".
En objective-c, cette sémantique n'existe pas, on doit tester tous les objects avant de les utiliser. Donc on peut supposer que le code appelant (qui est en objective-C) va tester l'objet renvoyé par LeChatNoir.
Il ne faut pas oublier que, comme les UITableView, cette vue est interconnectée avec une liste dont le délégué est responsable de récupérer le nombre des articles dans la liste et, du coup, la vue n'enverrait jamais un index au-dessus ce nombre. (sauf si l'auteur de la vue est null ::) )
En objective-c, cette sémantique n'existe pas, on doit tester tous les objects avant de les utiliser. Donc on peut supposer que le code appelant (qui est en objective-C) va tester l'objet renvoyé par LeChatNoir. (Ne jamais faire confiance à un chat...)
Ah oui, je parle du Swift pur, moi .. L'hybridation c'est pas ma tasse de thé.
Tant qu'à partager mon code ici, je me disais que peut être, on pourrait faire un framework "VerticalPhotoViewer" qui "mimic" un peu celui de Facebook.
Il est dépendant de SDImageView.
Si y en a qui sont partants, je veux bien me lancer. Sinon, ça restera dans les cartons.
Réponses
Ah ben en fait, en faisant ça, c'est ok :
LeChatNoir, s'il te plaà®t utiliser les balises "code" dans tes messages.
Pourquoi ta méthode prend un UInt pour l'index ? Si tu la mettais comme Int, tu n'aurais pas les problèmes de casting.
Si self.bigPhotos est vraiment [MWPhoto], il n'y a pas besoin de faire le cast as! MWPhoto
Ok Joanna, désolé.
La méthode citée plus haut est une méthode delegate de l'objet MWPhotoBrowser que j'ai récupéré via cocoapod. Je n'ai donc pas la main dessus.
Au final, tout fonctionne.
Je posterai le code de mon controller ici pour "analyse/corrections/cas d'école" car certains trucs que j'ai fait risquent de choquer les puristes
Une meÌthode qui renvoie un implicitly unwrapped optional d'après sa signature et qui se retrouve à pouvoir renvoyer nil y'a que moi que ça choque ?
Soit renvoie un optional directement ou mets un assert sur index < self.bigPhotos.count parce que c'est une très mauvaise habitude à prendre. (Un peu de lecture sur le sujet)
non, non.
Cette méthode est une méthode delegate.
Le code que tu reprends est le code qui ne marchait pas.
Le code corrigé est le suivant
Non monsieur. Moi aussi je partage ton indignation. LeChat, ton code corrigé vas cracher si ta méthode doit renvoyer nil.
Tueur de poneys ! >:(
Une variable de type WPPhotoProtocol! ne peut pas contenir la valeur nil. Ton code doit retourner une WPPhotoProtocol?
Voilà une fonction un peu plus propre.
Je me suis permis de remplacer self par photoBrowser sinon je vois pas l'intérêt de le passer en paramètre...
frimeur
/* je vais de ce pas regarder ce fameux guard
*/
Je vais aller faire un tour sur ce blog. Je vais en avoir besoin je crois
http://alisoftware.github.io/
Petite correction du code de Pyroh :
Or ce code plante direct car le photoBrowser n'est alimenté que par son delegate, c'est à dire mon viewController. Un peu comme une tableView.
Au final, ce code fonctionne :
Merci pour la correction. Je pense que quand je vais poster le code complet ici, y en a qui vont avoir une attaque cardiaque ::)
Pas normal ça.. ???
Il se passe quoi quand tu demande un index en dehors des clous ? Tu dois avoir un beau crash, avec ton code qui "fonctionne".
En fait, si, un implicitely unwrapped peut contenir nil.
Par exemple, ceci est possible :
Résultat:
En fait le "!" veut dire "je te garantis que je ne suis pas nil". Mais c'est surtout un contrat, s'il n'est pas respecté, le programme crash.
En interface avec swift les objects objective-C sont convertis en implicitly unwrapped, mais ils peuvent toujours être nil. Ce n'est pas quelque chose qu'il faut faire en swift pur.
En objective-c, cette sémantique n'existe pas, on doit tester tous les objects avant de les utiliser. Donc on peut supposer que le code appelant (qui est en objective-C) va tester l'objet renvoyé par LeChatNoir.
(Ne jamais faire confiance à un chat...)
Il ne faut pas oublier que, comme les UITableView, cette vue est interconnectée avec une liste dont le délégué est responsable de récupérer le nombre des articles dans la liste et, du coup, la vue n'enverrait jamais un index au-dessus ce nombre. (sauf si l'auteur de la vue est null ::) )
Ah oui, je parle du Swift pur, moi .. L'hybridation c'est pas ma tasse de thé.
En revanche, les nounours sont toujours fiables 8--)
Je ne suis pas certain que les pots de miels soient du même avis.
fiableS
Je suis en train de lire le blog d'Ali et ....
je me sens complètement largué
La prog fonctionnelle, j'ai l'impression que c'est la prog qui va me faire entrer dans la catégorie des développeurs de l'ancien temps...
Qu'est-ce qui te pause problème ? On peut peut-être aider nous.
C'est gentil ça
T'inquiète, je continuerai ce post. J'ai encore qques trucs à finir et tu vas te régaler
C'est un peu difficile au début en effet. Moi j'en fais depuis un an au boulot (en F#) et ça commence à aller bien mieux.
Pour la programmation fonctionnelle en swift, je conseille le livre Fonctional Swift, que je trouve très bien (et écrit par des pro).
Merci de ton avis. Je me tâtais à l'acheter vues les critiques.
Tant qu'à partager mon code ici, je me disais que peut être, on pourrait faire un framework "VerticalPhotoViewer" qui "mimic" un peu celui de Facebook.
Il est dépendant de SDImageView.
Si y en a qui sont partants, je veux bien me lancer. Sinon, ça restera dans les cartons.
Pour te rassurer, en anglais :
http://blog.cleancoder.com/uncle-bob/2016/07/27/TheChurn.html