Well, if you try the Bukkit method, you would run into problems because you have to use TextSerializers.FORMATTING_CODE.deserialize(string)
to parse &x codes.
While I like the idea of taking in parameters in the same way as Text.of(…), I feel as though it adds some unnecessary clutter to the MessageReceiver class that doesn’t particularly do much other than save 9 characters for the plugin authors.
It would add a large number of methods to MessageReceiver that aren’t particularly important. The only real benefit is that it makes switching from Bukkit/Spigot slightly easier, and saves a tiny bit of space in people’s plugins, which I don’t think warrants change to the way it is handled.
There is another benefit: style. Personally, I don’t like a lot of explicit factory/of methods that just become nested sequences of methods. Furthermore, the only reason the API exists is to make it easier for plugin developers, and, in my opinion, the best place for boilerplate like this is indeed in the API, not in the plugin. Of course, I can see the reason that it wouldn’t be included, and that argument is valid and makes sense too.
I believe it would be the most versatile and easiest to use… You could also potentially add a method with Object... or String... parameters that does each on a separate line, like sendMultiLineMessage(Object...) and perhaps one which uses color codes called something like sendColorCodeMessage(String message)
Just my two cents… plus my previous two cents, so now it’s like four cents. I just don’t think we need to clutter the entire interface with override methods, but a couple convenience methods would be nice.
I think it’d be very nice actually, and fits in with MessageReciever#sendMessage(Text...):
"This is line 1",
"This is line 2",
"Oh look, here is another line!");
If you wanted another useful utility method, another variation could be MessageReciever#sendMessage(TextSerializer, String...), whic deserialises the Strings using the provided TextSerializer. Might be overkill though.
It doesn’t make sense to do so though - and I can’t see why they should be in Text.of. TextSerializers are two way converters, for storing and retrieving stored messages, whilst Text.of() is one way, and intended for building up a message within the code - so using a serialiser should be pointless. They are two different systems for two different use cases.
In addition, Text.of uses the contents of the objects to build a message. It would not make sense to put a TextSerializer in Text.of, because that breaks how Text.of works with every other object.
I think it would be better to have just 2 methods than anything else: sendMessage(Object... objects) (For shorthand of Text.of(Object... objects)) and sendMessage(TextSerializer serializer, String message) to deserialize the Strings. Of course, with TextSerializer the text serializer param, you add more code to plugins which is undesirable, so perhaps also just a basic sendMessage(String message) which passes it to TextSerializers.FORMATTING_CODE for deserialization. As for multiple lines, the sendMessages method signature would be preferable as it indicates it’s function more clearly.
EDIT: It would be better not to format a basic String and let Object… handle it.