Let's simplify MessageReceiver's method sendMessage()

Sponge Sponge Development
1

Just an Idea.
What if we create a new method inside the MessageReceiver interface that will look like this:

default void sendMessage(String message) {
  this.sendMessage(Text.of(message));
}

and

default void sendMessages(String... messages) {
    for (String message : messages) {
        this.sendMessage(Text.of(message));
    }
}

So now we would be able to use these functions like this:

public CommandResult execute(CommandSource src, CommandContext args) throws CommandException {
	
	src.sendMessage("Message");
	
	return CommandResult.success();
}

Instead of:

public CommandResult execute(CommandSource src, CommandContext args) throws CommandException {
	
	src.sendMessage(Text.of("Message"));
	
	return CommandResult.success();
}

That would make things easier when we just want to display unformatted text.

1 Like
2

Just implementing all of the versions of Text.of() in MessageRecievers would be perfect.

3

Can you explain better what you mean? :smiley:

4

Just every format that Text.of takes in parameters. You might have it right, but.

5

Yeah that would simplify life a bit :smiley:

6

The only problem I see with this is people trying to use it like the way you format messages in Bukkit. Though I’m sure that’s not that big of a concern.

7

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.

8

It sure would make the code look cleaner / simpler, plus it’s a lot more straight forward

9

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.

10

I, personally, like this, and that’s probably the only reason why it would become an actual feature. Enough people liking the idea, not really how much sense it makes or how useful it is.

11

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.

1 Like
12

Well, the forums are all well and good, but if you want it to get done, make a pull request on GitHub.

13

OK I will start with it tomorrow, just wanted to know if that feature will be useful to others :smile:

14

What I’d suggest is just adding one method:

default void sendMessage(Object... message) {
    this.sendMessage(Text.of(message));
}

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.

2 Likes
15

That would, well, do exactly what we want.

But sending a multi line message through a method isn’t exactly what I’d call nice.

16

I think it’d be very nice actually, and fits in with MessageReciever#sendMessage(Text...):

messageReciever.sendMessage(
    "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.

17

I’d prefer that to be an actual Text.of feature rather than a send message feature, honestly. The serializing stuff.

18

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.

19

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.

20

If you’re going to have Object… Then what’s the point of a separate method?