Entity
suffixesThis is just dropping Entity
for regular entities and not BlockEntities, yeah?
Yeah.
Sponge does not use Entity
suffixes as well.
+1 but can't that argument also be used to things like blocks? It almost never clash. I like the idea of blocks. Chest but if you're making something that isn't strictly block related, it will be strange.
I disagree for consistency's sake
The thing with the Block
suffix, IMO, is that it denotes not just a block, but the block. Take grass for example, there's only ever one instance of a GrassBlock
at any given time, so it's safe to say "this is the grass block". Entities don't really work like this, because there's an instance of the entity for each one in the world. So, as another example, with zombies, you can't say "this is the zombie", because there are multiple zombies, not just one. You'd say "this is a zombie".
On the other hand, the consistency argument makes a good case - it's a bit inconsistent if we suffix some things with their type and leave the others with no suffixes.
hmm, how about falling block?
@Sorixelle makes a really good point. But i think that we should find a reason to the suffix, yeah it's cool to not have on the name, but isn't consistent.
so ZombieEntity means the Entity type for zombies?
can't that argument also be used to things like blocks?
I disagree for consistency's sake
The difference is that we say "I have 5 stone blocks" (not "5 stone"), but "I have 5 sheep" (not "sheep entities").
If you say "I have 5 stone" please :+1: this issue
Imagine if we named the classes SheepThing
and ItemThing
.
That's exactly what we have, because "entity" is just a synonym for "thing" and "object".
Is "entity" a synonym for "thing" and "object"? Yes.
Does that mean that entity cannot be something more specific in Minecraft? No.
Entities encompass all dynamic, moving objects throughout the Minecraft world.
Would you be OK with the names SheepDynamicObject
or SheepGameObject
then?
"article", "object" and "thing" are synonyms of "item". Should we rename SwordItem
to SwordArticle
, SwordObject
or SwordThing
?
The point is that SheepThing
and ItemThing
are meaningless variations when the concept of an "entity" is well defined as something more specific than a "thing" or an "object" in Minecraft, just like "item".
I'm not saying that Entity is meaningless. I'm saying that it's a general term that's used for all dynamic things, the same way we have java.lang.Object
, but not StringObject
, IntegerObject
, etc.
The point I was trying to make by that comparison was that if Mojang had named Entity
Thing
instead, would you still be for having SheepThing
, ItemThing
?
"article", "object" and "thing" are synonyms of "item". Should we rename
SwordItem
toSwordArticle
,SwordObject
orSwordThing
?The point is that
SheepThing
andItemThing
are meaningless variations when the concept of an "entity" is well defined as something more specific than a "thing" or an "object" in Minecraft, just like "item".
I don't see a reason for making it more complex with item names into article or thing.
Shulkers are great examples of where removing the entity denotation can make things confusing due to similar naming scenario and a block entity, block and entity definition of same name.
I'm not saying that Entity is meaningless. I'm saying that it's a general term that's used for all dynamic things, the same way we have
java.lang.Object
, but notStringObject
,IntegerObject
, etc.
java.lang.Object
is a superclass of every class, and entity classes make up a fraction of that.
how would you separate Item from ItemEntity, for example.
Also, Java standard shows EnumSet, EnumMap etc, so base class is part of extenders
CompoundTag, ListTag, StringTag...
Adding the super type is common practice
Drop
for the entity for ItemType
for the registry element
The minecraft:item
registry is a Registry
of Item
, not ItemType
, and the entity type ID is minecraft:item
so it is ItemEntity
.
Sure, keeping Entity
suffix is no big deal. We can live with that.
Yeah, don't drop Entity suffix please. It will only lead to confusion, and instead of naming things accurately, we will just try to name things not to be confused with suffix-less entities
The point I was trying to make by that comparison was that if Mojang had named
Entity
Thing
instead, would you still be for havingSheepThing
,ItemThing
?
Yes, because Thing
would have a specific meaning in that case.
Like Yanis said, dropping the suffix only leads to confusion. Names are for clarity, not "looking good".
Names are for clarity, not "looking good".
Names sounding natural is just as important as clarity.
Imagine I said while playing Minecraft "I'm going to kill some cow entities to get some raw beef items and then use a furnace block to turn them into cooked beef items".
Code matching the way we think and speak is a very good thing.
You can have both at the same time: a natural base (cow, raw beef, furnace), and a clarifying suffix (entity, item, block).
The point is that the suffixes are unnecessary. We know cows are entities and beef is an item. No one says "cow entity" or "beef item", so why should we have to say/read that when writing/reading code?
there's still the problem of ItemEntity
.
Yeah Item
is the sole reason I don't see this working. I probably wouldn't agree to it unless we did Item
-> ItemType
but that is an even bigger rename due to the shear amount of items in the game.
The other option is the clarify when names are ambiguous but that causes names to be inconsistent.
ItemEntity
-> DroppedItem
, similar to the way we have ThrownSnowballEntity
We know cows are entities and beef is an item. No one says "cow entity" or "beef item", so why should we have to say/read that when writing/reading code?
The only other option is to be inconsistent no matter the solution.
Dropping the suffix would cause issues with classes for content from different registries. The Item
base class is definitively named that way because there exists a registry full of it (or its subclasses) using the identifier minecraft:item
. Likewise, the ItemEntity
entity class is definitively named that way because its respective entity type is registered in the minecraft:entity_type
registry as minecraft:item
. The current Item
class would stay as Item
, but the ItemEntity
class would also become Item
.
If this specific issue was resolved by changing the name of the latter class to DroppedItem
or similar, then it would no longer match the identifier. This is a problem as there is enough faith in the identifier being a good representation for the class name that we have the current automatic system of naming fields in registry content classes, and adding the registry suffix to the class name.
The entire idea of dropping the suffixes is inconsistent with Java standard as well (see implementations of List or Map), as previously mentioned.
I probably wouldn't agree to it unless we did
Item
->ItemType
but that is an even bigger rename due to the shear amount of items in the game.
I'm sure there will be an ItemType
as soon as Mojang makes items data-driven, so it's best to hold off on this for now. Plus, this would still be inconsistent with the identifier and our current conventions regarding minecraft:x_type
registries.
ItemEntity
->DroppedItem
, similar to the way we haveThrownSnowballEntity
Once again, this would be inconsistent with Java standards and Yarn standards. I'm curious about any discussion regarding ThrownSnowballEntity
though considering its identifier is minecraft:snowball
.
The entire idea of dropping the suffixes is inconsistent with Java standard as well (see implementations of List or Map),
A HashMap
isn't a hash, but rather a hash[-based] map, and an ArrayList
is not an array, but rather an array[-based] list. A CowEntity
is a cow. It's a bit like saying we should say "cow animal" rather than "cow" because we say "pencil sharpener" rather than "pencil"...
Look at Java AWT. Everything extends Component
, but we just have Button
rather than ButtonComponent
, Scrollbar
rather than ScrollbarComponent
, etc. So if we follow the Java standard, we should get rid of suffixes.
If this specific issue was resolved by changing the name of the latter class to
DroppedItem
or similar, then it would no longer match the identifier.
I agree that matching the identifiers is important to make classes easy to find, but I don't see why we have to match it completely. Adding some clarifying words such as Dropped
is ok.
Between "match all the identifiers perfectly to satisfy my OCD" and "have names that are nice to use", I'd choose the second.
I'm sure there will be an
ItemType
as soon as Mojang makes items data-driven, so it's best to hold off on this for now
I think Item
-> ItemType
(as well as Block
-> BlockType
) is very important and should be done as soon as possible. Item
is just wrong, since there isn't an instance of the class for every item. It even leads to people new to modding to make the mistake of storing the item's state in fields in the item class.
inconsistent with the identifier and our current conventions regarding
minecraft:x_type
registries.
That convention doesn't make sense. The registries store item types and block types, not the instances of each individual item and block. The variation on the _type
suffixes is an inconsistency by Mojang, and we shouldn't copy it, just like we wouldn't copy a typo in an identifier.
To be honest Rune, "I'm going out to kill some cow entities" is not far from sounding natural to me, coming from the tech community.
If you want to make Minecraft read like natural language, there's a lot of other renames you can do. "I'm going to chop down some tree features" doesn't read well for anyone. Does that mean we should rename TreeFeature
to Tree
? No! But "cow entity" actually reads well. Especially in a context like "the server is lagging because there are a lot of cow entities in one place".
Does that mean we should rename
TreeFeature
toTree
?
Yes, the word Feature
here is redundant here. I'd also suggest adding Generator
at the end of the feature classes, since they're actually generators for the features, not the features themselves. We'd have something like TreeGenerator extends FeatureGenerator
.
the server is lagging because there are a lot of cow entities in one place
I'm guessing the reason you'd word it like this is to put emphasis on the fact that it's entities, which happen to be cows, that are lagging the server.
But in general this emphasis isn't necessary. If I'm working on a regular mod that just adds content (not a performance improvement mod), I'd be thinking about "spawning some cows", not "spawning entities of the type cow", and I'd want to write my code that way.
But they _are_ Cow Entities, not Cows. The idea of a cow only exists in natural language - CowEntity specifically refers to the cow _entity_, not the entire concept of a cow. You wouldn't put code that relates to other parts of the cow - such as its drops - in that class.
This bikeshedding is just useless...
The Entity
suffix is clear as it doesn't let you doubt over "what is this class?". In the context of Minecraft Entity
is clearly not a synonym of Thing.
Also for fucking modders sake, don't introduce a breaking change this big, it's already complicated enough when updates come you don't have to make it harder for modders by fucking their workspaces because someone disliked the Entity
suffix.
Like sure, go ahead change it, and watch the whole world burn because now mods don't compile because of 500 errors. Sure there's migrateMappings but why would I have to run it for a change so meaningless.
This issue has been opened for 1 year, and it was not applied. And meanwhile people used the Entity
suffix. Personally I would be very pissed to see such a change being merged thus exploding all my current mod workspaces.
Also, ok natural language is cool and all, but this is specific to the game engine, trying to read code like a novel is just not possible.
I'm going to have to say no, too. There are a lot of cases when it would be ambiguous (the aforementioned ItemEntity
, as well as ArrowEntity
or TridentEntity
).
Im not a fan of this idea, I dont think it really boils down to how it said in spoken language. It should be consistant across yarn, and removing it from just entities seems odd, removing it everywhere (blocks and items) doesnt make any sense at all.
Looking at the vote, guess it's clear?
Do you call LivingEntity
: Living
or Entity
: nothing, the suffix provides consistency with other names, I agree @l-Luna with CowEntity
does not represent a Cow it represents a CowEntity
, a Cow
represents the entity, its drops, and its model/render-er. The Entity
suffixes are aren't hurting anybody, and I think they help add some clarification just in case, along with the fact that BlockEntity
is a used suffix as well. Just my 2 cents.
Do you call LivingEntity: Living or Entity:
I call LivingEntity
a "living entity", so that name should stay. I call CowEntity
a "cow", so that name should be changed.
My problem is you are trying to name things like it was server-side only, sure naming CowEntity
Cow
on a server-side only API would make sense as it's literally the entire concept of cow for a server.
But here there is also the client, naming CowEntity
Cow
is plain wrong as the cow is defined by it's Entity
which is the object handling the properties of the cow, how it interacts with the world and its goals; but also by its model and its renderer!
By naming CowEntity
Cow
you strip a big part of the meaning of the class and make it then misleading.
I would be fine with this if yarn was server-side only, but it is not.
Even on the server CowEntity
does not fully represent a cow as it also has loot tables stored separately in the data-pack. And when talking technically I do say CowEntity
instead of Cow
. We are not making a gameplay tutorial, we are making a technical mappings set. Yes you would call a ChestBlockEntity
a chest in normal game-play, but this isn't normal game-play, this is mod-making, where you don't want to confuse ChestBlock
, ChestBlockEntity
and the chest loot table. Yes, you should keep the suffix even if it is redundant for say creepers, because for other stuff the suffix is not redundant (LivingEntity
, Entity
, ItemEntity
), and IMO it is better to be consistent in technical information than grammatically correct.
Closing this since most are against it.
Most helpful comment
If you say "I have 5 stone" please :+1: this issue