For one, the block class is called CommandBlock
, not CommandBlockBlock
, and it also makes it a lot less clunky of a name. It seems like this might be an artifact from the prefix -> suffix move.
It's a CommandBlock
BlockEntity
not a CommandBlockBlock
Entity
But on that logic, the CommandBlock
class should be called CommandBlockBlock
.
You got a point ^^
Fair.
Personally I think there should be a double Block suffix. As it's a (Note Block) Block, not a (Note) Block
But on that logic, the CommandBlock class should be called CommandBlockBlock.
I think it should.
Also relevant here are the grass
and grass_block
blocks. Not sure how those are currently named, but probably should be considered within this context
I'm for CommandBlockBlock
Isn't the suffix intent to make it clear the type of the class? CommandBlock already contains, block, because it's a suffix created from mojang to denote, commands of type block. It isn't needed the BlockBlock here.
Except block isn't the suffix; the entire base class is. In this case, the suffix of any subclass of BlockEntity would be BlockEntity - as with every other base class in the current mappings - and the prefix of every subclass of BlockEntity is the entire class name of its block, including the prefix of that class name, thus the prefix is CommandBlock and the suffix is BlockEntity.
Removing one of the Blocks can be read as prefix CommandBlock with suffix Entity - implying it's a subclass of Entity at first glance - prefix Command with the suffix BlockEntity - implying that it's the BlockEntity of a block called Command and not CommandBlock at first glance - or simply as a shortened form of CommandBlockBlockEntity, thus introducing ambiguity.
That being said, most people should know by now that CommandBlocks have BlockEntities and not normal Entities and that CommandBlock starts with Command. However, the current way is consistent with the rest of the mappings, and consistency makes things easier, even if it doesn't roll off the tongue quite as easily.
the current way is consistent with the rest of the mappings
I don't think it is, because of CommandBlock
not being CommandBlockBlock
. Your point on ambiguity is good, though.
Most helpful comment
I'm for CommandBlockBlock