Il est à noter que pour la lazy var, il n'est pas utile il me semble (testé à l'instant dans un Playground) d'utiliser une closure.
Ce genre de construction "= { ... }()" n'est utile que quand ce qu'il y a entre les accolades est en fait un peu complexe, genre quand la valeur par défaut qu'on veut calculer tiens sur plusieurs lignes et pas juste une seule instruction.
Mais si ça tiens sur une seule instruction, on peut mettre l'instruction directement. Même si ce n'est pas une valeur littérale mais bien une instruction à exécuter :
lazy var name: String = self.dynamicType.defaultName
Ce qui fait qu'au final tout rentre dans l'ordre et tout est la logique même prévue par Swift.
Du coup ce n'est pas spécialement une solution alambiquée ou un workaround ou quoi, c'est bien LA solution logique et qui est celle prévue par Swift pour ça, et qui permet :
De ne pas s'embêter à calculer une valeur par défaut pour la propriété "name" si jamais au final on a pas besoin de cette valeur par défaut car on lui en fournit une autre (aspect "lazy")
De concentrer les initialisations de valeur par défaut des variables à l'endroit où on déclare lesdites variables, comme c'est préconisé dans l'iBook officiel, plutôt que de tout mettre dans le init.
class MyClass
{
private class var defaultName: String { return "I am parent MyClass" }
lazy var name: String = self.dynamicType.defaultName
init() {}
init(name: String)
{
self.name = name
}
}
class MySubClass : MyClass
{
private override class var defaultName: String { return "I am child MySubClass" }
}
Réponses
Il est à noter que pour la lazy var, il n'est pas utile il me semble (testé à l'instant dans un Playground) d'utiliser une closure.
Ce genre de construction "= { ... }()" n'est utile que quand ce qu'il y a entre les accolades est en fait un peu complexe, genre quand la valeur par défaut qu'on veut calculer tiens sur plusieurs lignes et pas juste une seule instruction.
Mais si ça tiens sur une seule instruction, on peut mettre l'instruction directement. Même si ce n'est pas une valeur littérale mais bien une instruction à exécuter :
Ce qui fait qu'au final tout rentre dans l'ordre et tout est la logique même prévue par Swift.
Du coup ce n'est pas spécialement une solution alambiquée ou un workaround ou quoi, c'est bien LA solution logique et qui est celle prévue par Swift pour ça, et qui permet :
De ne pas s'embêter à calculer une valeur par défaut pour la propriété "name" si jamais au final on a pas besoin de cette valeur par défaut car on lui en fournit une autre (aspect "lazy")
Mais bien sûr