This is a pretty big change if it ever happens, since my bot relies on it. Here goes nothing.
Current Problem
The current problem with the NameFlag API is that it's very tedious to use and feels very out of place. Take for example this code:
func (r *Roles) AーReset(m *gateway.MessageCreateEvent) error {
There isn't a lot of functions that have a flag as a prefix for their name in Go, let alone a ー
(Japanese dash) character. This function name is also very hard to type, and writing a function name like this basically involves copy-pasting the character around.
Another problem is that this API is not flexible at all. Current NameFlag functionalities are hard-coded, which not only make NameFlags useless, but also cluttered in the code.
With the introduction of the CanSetup
interface, subcommands can implement it with the Setup(*bot.Subcommand)
method, allowing access to the subcommand at runtime.
Proposal
Below is the pseudo-code example that I sketched out. It implements all current NameFlags with methods called in the Setup function.
func (cmds *Commands) Setup(sub *bot.Subcommand) {
// Raw
sub.SetName("GC", "GC")
// AdminOnly
sub.AddMiddleware("GC", middlewares.AdminOnly(cmds))
// GuildOnly
sub.AddMiddleware("Toggle", middlewares.GuildOnly(cmds))
// Middleware for all handlers ("*" == "")
sub.AddMiddleware("*", middleware.GuildOnly(cmds))
// Hidden
sub.Hide("GC")
// Plumb to the first handler. (>1) == UB
sub.Plumb()
}
Middlewares
The biggest advantage of this change, other than getting rid of NameFlags, is the middleware. This API would allow users to arbitrarily implement any sort of middlewares, not just for the entire subcommand, but also for individual handlers.
Error Handling
Since this Setup function is called at runtime, calls should panic with an error. External subcommands could prevent this by writing a test that would call a helper function to check the Setup handler.
Anti-proposal
The NameFlag API does have its advantages. Initially, it was made with the idea that all methods should have their attributes marked near them. There wasn't any place other than the method name.
This is still true even with the Setup API. Clearly, the Setup API is typically on the top of the file (or any place), while methods could be any other place.
The API could also be improved and made more flexible. Issue #23 proposes a NameFlag handler repository and interfaces for different handler implementations. However, NameFlag characters are limited, so this isn't a very sustainable idea either.
Conclusion
In conclusion, I personally support deprecating the NameFlag API in favor of the Setup API. I think the Setup API has a lot more room for additional features. The NameFlag API, limited by the number of (sane) characters, would not be very good.