[Résolu] Date et représentation locale [code Mis À Jour]

Céroce

Il n'y a qu'un branche sur le git. As-tu déjà  fusionné dans master ?

Sinon, avec Swift 2, on peut mettre des méthodes dans un protocole. Cela répond peut-être à  ta question.

Pour moi, il y a encore pas mal d'améliorations possibles:
- À la place des variables privées currentDateFormat et currentRegionFormat, je m'attends à  avoir des propriétés publiques .dateFormat et .regionFormat. Tu devrais aussi avoir une propriété pickerView.
- tu as une méthode setPickerToCurrentDate(). Remplace-la par une méthode setDate(). En effet, j'ai l'impression que tu changes la date affichée à  d'autres endroits.
(Par ailleurs .date devrait aussi être une propriété publique).
- je ne suis pas certain que la méthode getRangeOfComponentsWithFormat() soit utile. Certes, tu peux commencer par la mettre dans DateFormat. Mais tu peux aussi mettre les valeurs en dur:
 

protocol DateFormat {

var componentsRanges: [Range<Int>] { get }

}



struct YearMonthDayDateFormat: DateFormat {

let componentsRanges = [Range<Int>(start: 0, end: 1), Range<Int>(start: 2, end: 3), Range<Int>(start: 4, end: 5), Range<Int>(start: 6, end: 7)]

}

C'est discutable, parce que ça demande plus de travail pour ajouter de nouveaux formats, mais en même temps, c'est plus flexible, et il y a moins de chance que ce soit bogué

- getStringRepresentationOfPicker(): je la retirerais. UIPickerView a une propriété .date, on peut utiliser un NSDateFormatter pour la convertir en string.

P.S.: En Cocoa, les getters n'ont habituellement pas un nom commençant par get.

AliGator

@Ceroce

// En Swift, on préfère utiliser

0...1

// Plutôt que

Range<Int>(start: 0, end: 1)



let componentsRanges = [0...1, 2...3, 4...5, 6...7]

Mayerick

Merci Ali, c'est la solution que j'espérais qu'il existe, ça répond parfaitement à  la question. Très bien je vire les points-virgule, même si j'aime bien personnellement, ça structure mais soit. Je n'en mettrais plus à  l'avenir et je nettoie ça. Bien noté pour SwiftLint, je regarde ça !

 

Céroce tu es sûr ? C'est bizarre car chez moi elle apparait bien sur git : 

 

Céroce

@AliGator c'est équivalent ? Je veux dire, cette syntaxe donne bien un Range au final ?

Céroce

• Je ne vois pas du tout ce que tu veux dire là , c'est un UIDatePickerView qui à  une propriété .date et non un UIPickerView, tu confonds malheureusement. Et au final justement, j'extrais tous les composants sélectionnés du picker pour construire un string.

Euh oui, exact. Pardon.

Mayerick

pas de souci ça arrive !   Tu as réussi à  avoir la protocolBranch ?

 

Edit : Point virgule supprimés de partout, et factorisation du protocole avec les defaults implémentations comme suggérée par Ali. Git à  jour, toujours bien prendre la branche protocolBranch.

 

re édit ça bug je corrige. raaaah.

 

Final édit: ça fonctionne, le code est formaté au plus propre, les ":" sont bien placés, les ";" enlevé. (enfin presque mais au prochain push il n'y en aura plus). 

samir

@AliGator c'est équivalent ? Je veux dire, cette syntaxe donne bien un Range au final ?

 

 

Swift Lib:

public func ...<Pos : ForwardIndexType where Pos : Comparable>(start: Pos, end: Pos) -> Range<Pos>

AliGator

@AliGator c'est équivalent ? Je veux dire, cette syntaxe donne bien un Range au final ?

Oui c'est équivalent... mais c'est une très bonne question quand même

En fait l'opérateur "..." (et son compagnon "..<") ont plusieurs surcharges.
Une variante qui génère Un Range, une autre qui génère un ClosedInterval (ou HalfOpenInterval pour "..<").

func ...<T : Comparable>(start: T, end: T) -> ClosedInterval<T>

func ...<Pos : ForwardIndexType>(minimum: Pos, maximum: Pos) -> Range<Pos>

func ...<Pos : ForwardIndexType where Pos : Comparable>(start: Pos, end: Pos) -> Range<Pos>

Mais sans plus de précision sur le type, c'est un Range qui est créé, car d'après les règles de prédominance des fonctions, Swift préfère toujours le type le plus spécifique. Ici vu que tu passes un Int, et qu'un Int est un type qui se conforme à  la fois à  ForwardIndexType et à  Comparable, il prend par défaut la définition la plus spécifique donc la dernière plutôt qu'une des 2 autres qui sont moins spécifiques car ne sont contraintes que sur un protocole et pas 2.

Du coup on a :

// Si tu ne précises pas particulièrement de type ça crée un Range

let range = 1...5 // == Range<Int>(start: 1, end: 5)

// mais si tu es spécifique :

let interval = 1...5 as ClosedInterval // == ClosedInterval(start: 1, end: 5)

let interval2: ClosedInterval = 1...5  // == ClosedInterval(start: 1, end: 5) aussi

Pour plus d'informations détaillées voir cette suite d'articles de blog (en 6 parties)


---

PS : Range est surtout utilisé pour une collection d'indexes dans une collection (les indexes de différents caractères dans une chaà®ne par exemple, ou un range d'index dans un tableau pour en extraire ou travailler sur une sous-partie) " c'est d'ailleurs pour ça qu'ils doivent être de type ForwardIndexType, qui est le genre de type utilisé pour les index dans une collection / liste, et sur lesquels tu vas pouvoir itérer, demander l'élément suivant va next(), ...

Alors qu'un Interval (ClosedInterval ou HalfOpenInterval) est plutôt défini avec ses bornes min et max uniquement et utilise les comparaisons ("<" et ">") pour savoir si tu es dans l'interval " d'où le fait que les éléments d'un ClosedInterval doivent être Comparable pour utiliser "<" et ">".

Par exemple autant " 1...5 " va créer un Range par défaut car tu utilises des Int comme opérandes de l'opérateur qui sont à  la fois ForwardIndexType et Comparable, mais il est tout à  fait possible d'utiliser un autre type d'opérande et de par exemple écrire " "a"..."z" ", qui dans ce cas créera un ClosedInterval (représentant "les lettres minuscules de a à  z"), ce qui est logique car de toute façon ça n'aurait pas de sens que ce soit un Range, qui est un groupe d'index et Character c'est pas un index genre ForwardIndexType (par contre c'est Comparable, donc ça a du sens de tester si "d" est dans l'intervalle "a"..."z")