Dans de nombreux endroits, les IBlockState
sont utilisés à des endroits où Block
auraient été dans le passé. J'ai presque envie d'appeler des paramètres de ce type block
car cela me semble plus logique. Qu'est-ce que tu penses?
De plus, cela soulève la question de savoir si IBlockState
devrait simplement être renommé en IBlock
, et Block
en BlockType
, ou quelque chose du genre ? Bien que ce soit peut-être un peu trop tôt, vous devriez au moins attendre ce que Mojang va faire à Blocks..?
state
.
Et IBlockState
devrait rester tel quel, IMO.
Similaire avec ItemStack
. Je le considère comme une instance d'un item
plus qu'un stack
qui n'entre de toute façon en jeu que pour les objets empilables. Je pense également à IBlockState
comme une instance d'un bloc dans le monde, lorsqu'il est transmis à des méthodes comme celle-ci.
Pourquoi pas des paramètres sans ambiguïté comme itemStack
, blockState
?
@mezz Parce qu'ils sont longs et n'ajoutent vraiment rien. Idéalement, un paramètre ne doit pas être nommé d'après le type mais son utilisation dans le code. Et à l'usage, je pense souvent à ce paramètre comme à "l'"élément" sur lequel la méthode fonctionne".
Cela peut être déroutant car nous avons la classe Item
mais disons que nous l'avons renommée en ItemType
, ce qui me semble plus logique puisqu'une instance de Item
n'est pas une instance d'élément mais décrit un type d'élément, cela éliminerait cette confusion.
D'après ce qui a été discuté dans irc à plusieurs reprises, il semble que nous allons avec state
moins qu'il n'y ait plusieurs types d'états tels que plus d'un BlockState ou un BlockState et un FluidState dans le contexte.
Oui.
Commentaire le plus utile
Pourquoi pas des paramètres sans ambiguïté comme
itemStack
,blockState
?