Et ça veut dire quoi ? En quelle situation crois-tu qu'elles ne marchent pas ?
L'idée c'était de renvoyer à celui qui ajoute une closure un token pour qu'il puisse enlever la closure puisque que tu disais dans la première partie que le "-=" ne fonctionne pas.
Par exemple dans Realm, tu peux faire:
let token = realm.addNotificiationBlock( { ... })
...
token.stop()
Ce qui ne marche pas, c'est de stocker ce token dans l'enum à côté de la closure.
L'idée c'était de renvoyer à celui qui ajoute une closure un token pour qu'il puisse enlever la closure puisque que tu disais dans la première partie que le "-=" ne fonctionne pas.
Par exemple dans Realm, tu peux faire:
let token = realm.addNotificiationBlock( { ... })
...
token.stop()
Ce qui ne marche pas, c'est de stocker ce token dans l'enum à côté de la closure.
Mais, avec mon code, il n'est pas nécessaire de renvoyer un token pour stocker ailleurs. L'enum tient le closure là dedans et tu peux ajouter et retirer les enums d'un array parce que il sont Equatable.
Le premier article parle de l'idée de stocker les closures, mais j'ai dit là qu'il n'est pas possible de retirer les closures "nus" d'un array ; c'est pour cette raison que je parle, dans le deuxième article de la solution de les emballer dans les enums.
Tous que tu y trouves autour de Event et Closure est un exemple du pattern observer. Mais, à la place d'ajouter les objets "entiers" comme observers, avec les Events, on ajoute plusieurs closures comme observers.
Avec les observers "classiques" :
{
public var subject: Person
{
didSet
{
subject.addObserver(self, forKeyPath: "age", options: .new, context: nil)
}
}
public override func observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey : Any]?, context: UnsafeMutableRawPointer?)
{
if keyPath == "age"
{
updateView()
}
}
}
Avec les observers 'closures" :
{
public var subject: Person
{
didSet
{
subject.propertyChanged += .didChange
{
[unowned self] _, args in
OK, FKDev avait raison en disant que les enums ne marchent pas ; au moins en partie.
On peut bien supprimer les enums d'un array mais, en cherchant pour l'index d'un enum dans un liste d'enums du même case, on tombe sur le premier élément qui correspond, qui ne pourrait pas être le bon.
Je l'ai découvert en préparant pour mon prochain article, qui utilise les Events et les Closures ; j'ai déjà trouvé une solution et je suis en train de préparer l'article mais, cette fois, j'emploie un beta testeur avent de le publier ::)
Réponses
Ah ok, un petit lien ou un petit rappel peut-être que c'est défini dans le 1er article, ce serait sympa.
Sinon pour l'idée du dessus, le problème c'est que les enums sont des value-types donc cela ne va pas marcher.
Juste pour toi, je l'ai fait :-*
Et ça veut dire quoi ? En quelle situation crois-tu qu'elles ne marchent pas ?
L'idée c'était de renvoyer à celui qui ajoute une closure un token pour qu'il puisse enlever la closure puisque que tu disais dans la première partie que le "-=" ne fonctionne pas.
Par exemple dans Realm, tu peux faire:
Ce qui ne marche pas, c'est de stocker ce token dans l'enum à côté de la closure.
Mais, avec mon code, il n'est pas nécessaire de renvoyer un token pour stocker ailleurs. L'enum tient le closure là dedans et tu peux ajouter et retirer les enums d'un array parce que il sont Equatable.
Le premier article parle de l'idée de stocker les closures, mais j'ai dit là qu'il n'est pas possible de retirer les closures "nus" d'un array ; c'est pour cette raison que je parle, dans le deuxième article de la solution de les emballer dans les enums.
Ah ok j'ai raté ce passage. C'est ok pour l'exemple du delegate.
Mais je cherchais une solution pour l'exemple du pattern observer.
Tous que tu y trouves autour de Event et Closure est un exemple du pattern observer. Mais, à la place d'ajouter les objets "entiers" comme observers, avec les Events, on ajoute plusieurs closures comme observers.
Avec les observers "classiques" :
Avec les observers 'closures" :
OK, FKDev avait raison en disant que les enums ne marchent pas ; au moins en partie.
On peut bien supprimer les enums d'un array mais, en cherchant pour l'index d'un enum dans un liste d'enums du même case, on tombe sur le premier élément qui correspond, qui ne pourrait pas être le bon.
Je l'ai découvert en préparant pour mon prochain article, qui utilise les Events et les Closures ; j'ai déjà trouvé une solution et je suis en train de préparer l'article mais, cette fois, j'emploie un beta testeur avent de le publier ::)
En suivant les conseils de FKDEV, j'ai ajouté du texte dans https://joannamacdev.github.io/Observers-Event-And-Closures/
Cherchez "Danger, Will Robinson !"
Très belle initiative Joanna !
Je suis moi même en train d'en concevoir un de mon côté mais il est bien moins technique.
ça-y-est ! Prochain article disponible sur mon blog https://joannamacdev.github.io/Observers-Event-And-Closures-Part-3/
Et maintenant, pour les accrochés, la première partie d'une série sur les Interactors https://joannamacdev.github.io/Interactors-Part-1/
Hum .. Il vas me falloir un grand bol de Google traduction ! ???
Encore deux articles su les interactors sur mon blog.
Ceux contiennent le code de validation pour les nombres entiers et les décimaux. Attention ! C'est compliqué !
Si quelqu'un entre vous veut chercher pour les bogues, je serais preneur de tous vos commentaires
https://joannamacdev.github.io/Interactors-Part-2/
https://joannamacdev.github.io/Interactors-Part-2-Decimal-Numbers/
Nouveau article dispo.
Cette fois, c'est sur les types génériques.
https://joannamacdev.github.io/Heterogeneous-Generic-Collections/