En Scala, qu’est-ce qu’un "initialisateur précoce"?

Question

Dans son récent article sur les niveaux de capacité de programmeur dans Scala, Martin Odersky inclut dans la section Concepteur de bibliothèques expert le terme "premiers initialiseurs" .

Celles-ci ne sont pas mentionnées dans Programming in Scala . Que sont-ils?

Answer 1

Les initialiseurs précoces font partie du constructeur d'une sous-classe destinée à être exécutée avant sa super-classe. Par exemple:

 abstract class X {
    val name: String
    val size = name.size
}

class Y extends {
    val name = "class Y"
} with X
 

Si le code a été écrit à la place

 class Z extends X {
    val name = "class Z"
}
 

alors une exception de pointeur nul se produirait lorsque Z serait initialisé, car size est initialisé avant name dans l'ordre normal d'initialisation (superclasse avant classe).

Answer 2

Pour la syntaxe et la motivation, regardez ici: https://github.com/paulp/scala-faq/wiki/Initialization-Order (on les appelle "définitions précoces", mais c'est la même chose)

Answer 3

Aussi loin que je peux dire, de la motivation (comme indiqué dans le lien ci-dessus) est:

"Naturellement quand un val est dépassé, il n'est pas initialisé qu'une seule fois. Donc, si x2 dans l'exemple ci-dessus est apparemment défini en chaque point, ce n'est pas le cas: un substituée val apparaît nulle lors de la construction de super-classes, comme un résumé val."

Je ne vois pas pourquoi ce qui est naturel à tous. Il est tout à fait possible que la r.h.s. d'une cession pourrait avoir un effet secondaire. Note qu'un tel code de la structure est complètement impossible en C++ ou en Java (et je suppose que Smalltalk, bien que je ne peux pas parler cette langue). En fait, vous avez à faire une telle double affectations implicite...ticilpmi...Explicite dans ces langues par les constructeurs. À la lumière de la r.h.s. effet secondaire de l'incertitude, il n'a vraiment pas sembler beaucoup d'un la motivation à tous: la capacité à contourner la superclasse des effets secondaires (ainsi la miction superclasse invariants) par l'intermédiaire d'AFFECTATION? Ick!

Existe-il d'autres "killer" motivations pour permettre à ces dangereux de la structure de code? Les langages orientés objet ont fait sans un tel mécanisme d'environ 40 ans (de 30 années impaires, si l'on compte à partir de la création de la langue), pourquoi maintenant?

...Juste...semble...dangereux.

Answer 4

Sur la deuxième pensée, un an plus tard...

C'est juste un gâteau. Littéralement.

Pas un début de quelque CHOSE. Juste à gâteau (mixin).

Le gâteau est un terme/modèle inventé par Le Grand Pooh-bah lui-même, celui qui emploie à la Scala, à la caractéristique du système, qui est à mi-chemin entre une classe et une interface. C'est beaucoup mieux que Java du modèle de décoration.

Le soi-disant "interface" est simplement un sans nom de la classe de base, et que ce qui la classe de base est d'agir comme un trait de caractère (qui franchement, je ne sais pas qui pourrait être fait). Il est clair pour moi si un "d" class peuvent prendre des arguments (les traits ne peuvent pas), l'essayer et d'en faire rapport.

Cette question et sa réponse a entré dans un de la Scala de fonctionnalités les plus intéressantes. Lire et être dans la crainte.