Migrate from prefixes to suffixes

[kashike]

We're planning to do the following changes to make things consistent, and 1.14 is a good time to do it with the large changes.

Do note that these are only what vanilla names will use - you're free to name your own classes in your mods however you like.

---

Propsed change

• Migrate from prefixes to suffixes for everything: FooBlock, FooItem, etc
  • not everything with a Block prefix is actually a block (applies elsewhere too):
    • BlockMatcher is actually a predicate
    • BlockPattern is actually a pattern that can be matched in the world
    • BlockState is actually a state of a block
  • doesn't apply to vanilla, but applies to mods who don't use packages and follow vanilla's class naming: FooBlock, FooItem are both grouped together, rather than BlockFoo [... many others ...] ItemFoo
    • while vanilla separates blocks and items into their own packages, a mod is not required to do the same
  • note that we already use suffixes for major refactors and new classes: see Biome and Feature classes for an example
  • Historical Note: This is a hold over from back before packages were a thing with MCP - we essentially faked packages by grouping class names together with prefixes

---

Please react with 👍 if you are in favour, and 👎 if you are not in favour.

It it HIGHLY encouraged that you read all responses to this, you can change your vote at any time up until the deadline. Please take this seriously as all results are final after the deadline.

Deadline for feedback and voting is Noon PDT Monday (29/04/2019).

ref #814

[williewillus]

point: upends naming of everything in the community for little benefit. I don't particularly feel strongly for prefixes and would have abstained, but I despise needless churn in an already churny modding scene (thanks to vanilla).

there's bigger fish to fry w.r.t class names (Dimension vs DimensionType, WorldInfo, ...) than to worry about the block and item names, which are straightforward and easy to understand regardless of which choice we pick here.

[bs2609]

counterpoint: maybe people will care enough to contribute to the migration tools everyone ignores (e.g. https://github.com/MinecraftForge/Remapper)

[LexManos]

As for the "bigger fish to fry" 1.14 is the time. Kashike will be curating all open issues for class renames. Go vote on those specific issues. This issue has no effect on any others except for if those are smurphed names. In which case they will be updated to follow whatever outcome this vote has.

[DarkGuardsman]

Problem with this is if you start importing classes with the same name. So say we had BlockMatcher and ItemMatcher then we dropped the prefix. This would mean we have two Matcher.class. Effectively resulting in more complex importing. Not saying this is actually the case but should be considered. As a minor change like this could result in less than minor complexity for developers.

The other issue is when dropping prefixes it can make it difficult to understand what something means. In the case again of BlockMatcher, if you call it just Matcher then what context clue does the name provide? I rather not have to leverage the IDE or the import path to understand what a class is when reading code.

The final thing, what do we gain by dropping the prefix?

[cpw]

Not dropping the identifier @DarkGuardsman, moving it from prefix to suffix.

[LexManos]

Your example of "BlockMatcher" would not fall into this change. As it is not the "Matcher Block" it is a Matcher, that matches Blocks. But yes, the proposal is not to drop the type, it's to move it. So "BlockDirt" -> "DirtBlock"

[DarkGuardsman]

Oh.. my bad, the other two were 'dropped' with my brain recovering from an 11 hour shift at work doing a deploy....

anyways still against this idea. Its going to add way too much unneeded rename churn, create a massive amount of confusion, and invalid any tutorial/documentation we currently have. As a community that already suffers from docs/tuts shortage that is very harmful.

We really need to ask what advantage does this offer to veteran developers, noob developers, and new developers.

New developers will likely gain nothing from the change. As its still a lot to learn either direction you look at it. Honestly might be better as DirtBlock is easier to say in english then BlockDirt. Though this only applies to english as other languages fair differently.

Noob developers will learn the change eventually but could be stunted in terms of growth. Since they are currently in the process of learning with tutorials. That would then need to be updated or reworked to note the massive change in naming. Remember even a simple name change to a new developer is a lot to work around when you're not use to that type of change.

Old developers might just flat out quit rather than deal with running a rename tool over each project then fixing anything missed. I fall into this last part personally as I have well over 150+ MC repos. With my current job I can't spend more than 8 hours a week developing. Given I'm an edge case due to the scale I develop mods at currently. Most developers will recover after a short delay of a day or so. However, it would have a negative impact on workflow with no future gain in productivity.

[bs2609]

Tutorials and the like will become invalidated by Minecraft version changes in any case - this will not be the extent of 1.13/1.14 changes.

To some extent, if there is to be a change, it's better to "get it over with" - if these changes came with the introduction of packages, it would be well in the past and current developers would not be affected by it.

[bs2609]

Another point that is worth mentioning is that Mojang themselves appear to use suffix naming. I personally don't feel we should be governed entirely by "official" names, but I think it's worth keeping it in mind.