Yarn: MinecraftClient.openScreen -> setScreen

Oui, c'est parfaitement logique pour moi. Il n'y en a jamais qu'un.

oui, il change également d'écran, donc setScreen est en effet mieux

Pas fan de ce changement, vraiment. setScreen donne l'impression que cela ressemble à un simple setter, mais si le consensus est d'y aller... d'accord

Ou present / display / show ?

Si nous suivons les suggestions de Liach, à ce stade, nous avons l'impression de changer le nom pour le plaisir de changer les noms

Lol sinon il faut en tirer un qui plaise à la shartte

setScreen fait sonner comme un simple setter

L'intérêt d'un setter plutôt que d'un simple champ est d'avoir une logique supplémentaire exécutée lorsque le champ est défini (que cette logique supplémentaire soit déjà présente ou que vous souhaitiez avoir la possibilité de l'ajouter à l'avenir sans casser le code qui définit le champ ).

@liach Nah, pas besoin de me faire plaisir. Je ne pense pas que ce soit _particulièrement_ important, et je pense que le nom actuel est bien, mais le renommer setScreen n'est pas la fin du monde :-D

Autre suggestion : switchScreen

switchScreen(null) toujours un sens parfait, et il n'a pas le problème de ressembler à un passeur ou à une opération réversible.

Si nous suivons les suggestions de Liach, à ce stade, nous avons l'impression de changer le nom pour le plaisir de changer les noms

Je pensais que c'était le problème ici? Je trouve openScreen très déroutant, je passe cinq bonnes minutes à chercher un closeScreen , lastScreen , ou popScreen . Les objets qui ont un open devraient avoir au moins un close .

present / display / show pourraient potentiellement avoir le même problème, bien que leurs inverses ne soient pas aussi universels ( destroy , conceal , hide ).

setScreen est très bien, cependant, puisque les setters peuvent avoir plus de code que juste field = param . Yarn appelle déjà de nombreux setters plus longs setX même s'ils font plus que simplement définir la valeur d'un champ.