Message rework system

[OMAR-3OOV]

General Troubleshooting

• I have checked for similar issues on the Issue-tracker.
• I have updated to the latest JDA version
• I have checked the branches or the maintainers' PRs for upcoming features.

Feature Request

Recently data made the new message rework system which is one of the best things! but there are a few things I see that if it could change it would be better, from my side, I would know other opinions as well about this thing.

so basically there is MessageEditData / MessageCreateData is a new thing to make a difference between sending and editing I see that is not much complex, especially since there is a MessageData, I think if merging MessageEditData and MessageCreateData could be better generally, in my situation I have a MessageUtiltiy Class that I manage the messages that send and edit and I want to avoid making a lot of methods just to process the edited message and sent messages it's better if MessageData could process that to make the code way better and clean.

I still like the new rework I don't dislike it.

Example Use-Case

My example code:

----------------------------------------------------------- [MessageUtility class]

private MessageDataBuilder data = new MessageDataBuilder();

public MessageUtiliy create(Consumer<MessageData> consumer) {
         data.setAuther("Hello world!");
         consumer.accept(data);
         return this;
}

public MessageData build() {
         return data.build();
}

----------------------------------------------------------- [Event class]

MessageData data = messageUtility.create(data -> { 
          data.setDescribtion("Hello discord!") 
}).build();

// when message send
event.getChannel().sendMessage(data).queue();

// when message edit
message.editMessage(data).queue();

[MinnDevelopment]

The edit endpoint is different from the create endpoint, for this reason we have to use different bodies for this representation. Due to the high level of abstraction used in the rework, you can use abstracted interfaces for your logic:

// Abstract consumer can be used on either MessageCreateBuilder or MessageEditBuilder
Consumer<? super MessageRequest<?>> callback = (request) -> {
  request.setContent("hello");
  request.setEmbeds(embeds);
});

MessageEditBuilder edit = new MessageEditBuilder();
callback.accept(edit);

MessageCreateBuilder create = new MessageCreateBuilder();
callback.accept(create);

You can also use MessageEditData.fromCreateData(...) and MessageCreateData.fromEditData(...) to easily convert between the two.

Here is an example usage with generics:

class MessageUtil<T extends MessageData, B extends AbstractMessageBuilder<T, B>> {
    private final B builder;
    private final LocalizationStore localizations = new LocalizationStore();

    private MessageUtil(B builder) {
        this.builder = builder;
    }

    public static MessageUtil<MessageCreateData, MessageCreateBuilder> create() {
        return new MessageUtil<>(new MessageCreateBuilder());
    }
    
    public static MessageUtil<MessageEditData, MessageEditBuilder> edit() {
        return new MessageUtil<>(new MessageEditBuilder());
    }

...
    
    public MessageUtil<T, B> setMessage(String locale, String key) {
        builder.setContent(localizations.get(locale).message(key));
        return this;
    }

...
    
    public T build() {
        return builder.build();
    }
}

MessageCreateData data = MessageUtil.create().setMessage("de-DE", "error:unknown_user").build();

Similarly you can also use the same kind of generic code on the respective RestActions for the various endpoints. Each RestAction also implements the same MessageRequest interface and you can use your util class on it just like with builders. The rework thus provides high flexibility and works great on the different endpoints, unlike the previous design.