middleware

[naive junco]

So yeah, it wasn't clear to me how something like TranslationInteraction#reply wasnt replacing and possibly modifying the internal method

replacing probably more accurate

Unless its also a middleware step that would then be responsible for passing InteractionReplyOptions to the base method?

[jagged birch]

Well it's always an Interaction when discord.js uses it internally, so I don't think it has internal effects. When I create TranslationInteraction it doesn't modify the original interaction in place. It creates a new instance and then that instance is received by the user. Thats what the static TranslationInteraction#from does.

Replacing a method isn't something that can really be protected from subclassing. This is especially true for overriding a method that returns void. However this becomes the subject of good design vs poor design. If you have a method called reply() and don't have it actually reply properly, then you've rendered the interaction useless. It's same idea for frameworks we have today that subclass a Client. If that framework changed Client#login to not actually login, that's renders their framework unusable. I think intrinsically, it makes sense for middleware developers to properly implement/override methods.