New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop 'Entity' suffixes #407
Comments
This is just dropping |
Yeah. |
Sponge does not use |
+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 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? |
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 👍 this issue |
Imagine if we named the classes 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. |
Would you be OK with the names |
"article", "object" and "thing" are synonyms of "item". Should we rename The point is that |
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 The point I was trying to make by that comparison was that if Mojang had named |
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. |
|
how would you separate Item from ItemEntity, for example. Adding the super type is common practice |
|
The |
Sure, keeping |
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 |
Yes, because Like Yanis said, dropping the suffix only leads to confusion. 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 |
Yeah The other option is the clarify when names are ambiguous but that causes names to be inconsistent. |
|
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 If this specific issue was resolved by changing the name of the latter class to The entire idea of dropping the suffixes is inconsistent with Java standard as well (see implementations of List or Map), as previously mentioned.
I'm sure there will be an
Once again, this would be inconsistent with Java standards and Yarn standards. I'm curious about any discussion regarding |
A Look at Java AWT. Everything extends
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 Between "match all the identifiers perfectly to satisfy my OCD" and "have names that are nice to use", I'd choose the second.
I think
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 |
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 |
Yes, the word
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 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 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 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 |
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 |
I call |
My problem is you are trying to name things like it was server-side only, sure naming But here there is also the client, naming By naming I would be fine with this if yarn was server-side only, but it is not. |
Even on the server |
Closing this since most are against it. |
Entity
suffixesThe text was updated successfully, but these errors were encountered: