Converting NamespacedKey parameters to lowercase Strings#13910
Conversation
|
The other constructor is doing that because the plugin name can be not lowercase which is valid usage. Here this is masking invalid inputs without the developer properly considering side effects |
|
How is it valid usage because of the namespace being lowercase? The key in the other constructor is made lowercase automatically, so I thought this would be acceptable. |
It is made lowercase automatically when supplying a plugin as input because you do not control the input directly. Most plugins have a uppercase letter in their name somewhere which is a valid thing, and it would be a breaking change if every author would have to change this in order to use NamespacedKey. When specifying the namespace manually, you are in control, so this is no longer an issue and the correct requirements are enforced |
You do though? I was talking about the key, not the namespace. You directly control the key, but it is still made lowercase. Should this change be removed?
I haven't been talking about the namespace, I've been talking about the key. In both scenarios, you have full control over the key, but it is still changed to be made lowercase when the plugin class is specified. I also made the namespace string be lowercase because I thought it'd be weird to throw errors for a capitalized namespace but not for a capitaized key. |
|
I mean, we cannot really remove it now as it already exists in the plugin constructor of namespacedkey without breaking backwards compatibility. that bit of the namespaced key constructor was inherited from spigot, I agree with the above comments tho. Manually and quietly changing the key to lowercase seems only harmful when developers should very much be forced to use correct casing for these inputs. |
It does it in the other constructor where the namespace is derived from a plugin, but not when it is a string. It just runs
String#toLowerCaseon thenamespaceandkeyparameters, using the Locale.ROOT parameter.