Yarn: IBlockState parameters: state or block?

Created on 28 Oct 2016 · 6Comments · Source: FabricMC/yarn

In many places, IBlockStates are used in places where Block would have been in the past. I almost want to call parameters of that type block since it makes more sense to me. What do you think?

Additionally, this opens up the question of whether IBlockState should simply be renamed to IBlock, and Block to BlockType, or something? Though maybe that's a bit too early - should wait for what Mojang is going to do to Blocks, at the very least..?

discussion

Source

copygirl

Most helpful comment

Why not unambiguous parameters like itemStack, blockState?

mezz on 28 Oct 2016

👍2

All 6 comments

state.

And IBlockState should stay as it is, IMO.

shadowfacts on 28 Oct 2016

👍1

Similar with ItemStack. I think of it as an instance of an item more than a stack which only comes into play for stackable items anyway. I do think of IBlockState as an instance of a block in the world too, when it is passed into methods like this.

copygirl on 28 Oct 2016

Why not unambiguous parameters like itemStack, blockState?

mezz on 28 Oct 2016

👍2

@mezz Because they're long and don't really add anything. Ideally a parameter shouldn't be named after the type but its use in the code. And in use, I often think of said parameter as "the 'item' the method is operating on".

It might be confusing because we have the Item class but say we renamed that to ItemType, which makes more sense to me since an instance of Item is not an item instance but describes a type of an item, it would remove this confusion.

copygirl on 29 Oct 2016

From what has been discussed in irc various times, it sounds like are going with state unless there is multiple kinda of states such as more than 1 BlockState or a BlockState and FluidState in the context.