removed upper and lower for name

[pollend]

This issue for terasology shows kind of a key problem with transforming the name of the asset in gestalt. MovingBlocks/Terasology#3887 I think we should avoid transforming the name at all and just use the name that was provided by the asset. Any kind of additional transformation on the type seems like a good way to introducing bugs. for one case it might be uppercase but another case it could be lower. When systems intersect is where we will see kind of a mix of the two and working out if its one or the other seems like a major problem.

[skaldarnar]

I don't know whether removing/deprecating toLowerCase and toUpperCase is strictly necessary, but it will likely reduce misuse for later string comparison...

@immortius do you have any opinion on this? And what is the process of merging a change in gestalt and porting it back to v5?

[immortius]

Mmmm. I'm not against removing (or deprecating) the toUpper and toLower methods, but I think we should leave toString alone - toString exists for display, introducing a new function for this isn't necessary. Also don't think it is worth changing the spelling of normalised to a perhaps slightly more correct spelling when it is only used internally.

[pollend]

my main reasoning would be that toString should return the id of the object and that choosing to display it would be a more deliberate process. we probably do more comparisons using toString vs cases where we would display the name of the object. The default behavior would be to give back the normalized version because in most cases it would be used for a comparison right?

[skaldarnar]

I have to agree with both of you (to some degree). toString should be used for display, but unfortunately it isn't. Maybe @immortius is right and the main problem is that (basically all of) Terasology's code is using it wrong, but that's still no reason for changing the library.

However, I also agree with @pollend that it is a bit of bad design if it is too easy to use the class in a wrong way... toString is used implicitly in some cases, and most (new) Java programmers learn about that method, and whenever they try to compare a Name to a String they'll use the (case sensitive) one...

I'm wondering whether something like Names.compare(name, string) would help here, as it might be a bit more straightforward than name.compareTo(new Name(string)) 🤷‍♂️

[immortius]

We could also add Name::compareTo(String) if that would be more straight forwards.

[skaldarnar]

While at it - would it make sense to add contains(substring) and startsWith(prefix)/endsWith(suffix)? Would that be a bad idea as it would weaken the Name as a unit?

[skaldarnar]

Let's keep it as it was - less noise in the diff.

Suggested change

	private final String normalised;
	private final String normalisedName;

[immortius]

Cheers, I'm happy with this outcome.