Currently the net/minecraft/text has all of the text model components prefixed with TextComponent, in contrast with Mojang's own naming scheme (XComponent).
Its important to note that only TextComponent directly represents actual text, the rest are just placeholders apart a model that is constructed into text client-side. IMO the Text prefix is verbose and unnecessary.
I propose that we should use Mojang's naming (where known) and the following changes:
net/minecraft/text/ITextComponent->net/minecraft/text/Component(this is kind of given away in some of the serialisation code).
jamierocks
All 13 comments
I propose that we should use Mojang's naming (where known)
That has always been a bit of a controversial point: some Fabric developers argue the names should be improved upon where applicable instead. I, personally, believe that while the official names are an useful hint, we should treat them as just that - a hint. Additionally, I don't believe the names in toString always reflect the actual class name.
Anyhow, I'm opposed, but I'm a fan of verbosity.
- "Component" is a common keyword which can easily be imagined to occur in a lot of modded content patterns, potentially even not far from chat message-emitting code.
- Using or not using "I" to mark interfaces is, again, a point of debate - though I thought we generally settled on using it, with perhaps the exception of direct derivatives from Java interfaces (say, IntIterable extends Iterable).
asiekierka
on 28 Oct 2018
Fabric tends to use common prefixes all over the place, which is quite useful for IDE's auto completion and recognition. Not using Text* wouldn't fit everything else.
I'd rather drop the "Component" infix, it is technically wrong (the "component" usually references the whole thing, not a part ("component") of something) and doesn't add to readability.
sfPlayer1
on 29 Oct 2018
"Component" is a common keyword which can easily be imagined to occur in a lot of modded content patterns, potentially even not far from chat message-emitting code.
That's a fair point, though I don't think it'd make too big of a difference (its rarely imported) - the subclasses (Text, Score, etc) I really doubt could be apart another system so I don't think that's so much of an issue.
Using or not using "I" to mark interfaces is, again, a point of debate - though I thought we generally settled on using it, with perhaps the exception of direct derivatives from Java interfaces (say, IntIterable extends Iterable).
Well that's a different discussion, I have my preference but that can be discussed elsewhere - for the purposes of this discussion I'd be happy with either Component or IComponent.
Fabric tends to use common prefixes all over the place, which is quite useful for IDE's auto completion and recognition. Not using Text* wouldn't fit everything else.
Really? You'd certainly still get completion for TextComponent, and I would imagine the others too (given the package, but I guess that depends on IDE).
I'd rather drop the "Component" infix, it is technically wrong (the "component" usually references the whole thing, not a part ("component") of something) and doesn't add to readability.
Just because in a lot of cases only a single component is used, doesn't discount that many can be used (and frequently are - e.g. Press <x> button to jump). Component is an essential part of the name.
This thing is, while this is certainly apart the text model (hence net/minecraft/text) only one component (TextComponent) is actual text - the rest are placeholders for the client to fill-in. IMO it doesn't make too much sense to repeat the package for the components in the class name.
jamierocks
on 29 Oct 2018
They are all representing localizable text, usually to be displayed on the client. "Text" conveys naturally that it can be embedded into itself.
If you think about it from the other direction, the "component" has no real container, it is always constrained to itself until it gets consumed or exported into a string. "Component" is an unnecessary distinction towards something that doesn't exist. Stripping "Text" makes it as generic and meaningless as "Element", "Part" or similar, losing the description of its identity/purpose.
sfPlayer1
on 29 Oct 2018
About the package argument: I'm of the belief that you don't really look at package names when reading code...
asiekierka
on 29 Oct 2018
About the package argument: I'm of the belief that you don't really look at package names when reading code...
Sure, when reading code context is where you'd know its text related - package is only really relevant when importing. Though importing is the only case I see it being an issue anyhow...
// Even when using Component in a field, context easily allows you to
// know its text-related
final Component message = new TextComponent("Hello, World!");
player.message(message);
// Each of the components are fairly easily identifiable as text
player.message(new KeybindComponent("key.jump"));
player.message(new TranslatableComponent("info.kick", "player-x"));
player.message(new ScoreComponent("name", "objective"));
player.message(new SelectorComponent("pattern"));
Take a look at the examples for kyori/text, to see that even without the 'Text' prefix its still very easy to see what it means and looks a bunch cleaner too (IMO ofc).
jamierocks
on 29 Oct 2018
You might have a point with the code examples, though I'd still argue ScoreComponent/SelectorComponent/KeybindComponent can be confusing in certain contexts.
And I still wouldn't be so sure on calling the base "Component". Rubs me the wrong way.
asiekierka
on 29 Oct 2018
And I still wouldn't be so sure on calling the base "Component". Rubs me the wrong way.
Maybe, but it's not uncommon - take org.w3.dom.Node for example.
jamierocks
on 29 Oct 2018
I wouldn't removing Text prefix as Component alone wilk cause confusion as there are many similar class with same names exists
strikerrocker
on 14 Dec 2018
Okay but let's look at what happens in the reverse:
// Even without Component in the name, names are still focused on the object's use
// Note that I've reversed from StringText to TextString because it flows more naturally
// in english
final Text message = new TextString("Hello, World!");
player.message(message);
// Each of these objects' purposes are easily determined without the word "Component"
player.message(new KeybindText("key.jump"));
player.message(new TranslatableText("info.kick", "player-x"));
player.message(new ScoreText("name", "objective"));
player.message(new SelectorText("pattern"));
Seems legit to me.
falkreon
on 23 Dec 2018
Well, as kashike reminded me - Mojang do not call them text components - they call them chat components (you just need to look at the changelogs to know this).
They also don't refer to the text component as a string text component - text for them, is what fabric calls string.
jamierocks
on 23 Dec 2018
Yet another confirmation mojang calls them components
Prospector
on 28 Mar 2019
My research led me that are in a chat package in network for what's it's worth -> https://github.com/jamiemansfield/mcmap/tree/18w50a/workspace/net/minecraft/network/chat
(Edit: Silly mobile)
jamierocks
on 28 Mar 2019
Related issues
Runemoro
路
4Comments
copygirl
路
6Comments
Awakened-Redstone
路
4Comments
altrisi
路
4Comments
Draylar
路
6Comments
Most helpful comment
Fabric tends to use common prefixes all over the place, which is quite useful for IDE's auto completion and recognition. Not using Text* wouldn't fit everything else.
I'd rather drop the "Component" infix, it is technically wrong (the "component" usually references the whole thing, not a part ("component") of something) and doesn't add to readability.