Proposal: Arguments enhancement. about klasa HOT 5 CLOSED

I agree with this 100% all ideas look great as they all work but come with pro's and con's like everything does the ArgumentUsage way looks very nice and advanced but will this suit for beginners? not really IMO while it is very advanced and would be powerful it could also be a hassle for beginners to understand but that being said it won't take long to learn how it works.

Now while I also like the idea of UsagePrompt I don't see how useful it could be considering if you're going to go full out on a prompting class for usage prompts I would just go with the ArgumentUsage class idea which handles Usage as a whole excluding usageDelim as that has its differences as I see it ArgumentUsage seems the way to go its advanced and powerful unlike UsagePrompt which it would be plain and boring just handling prompts. yes, it could be advanced for handling prompts but why would it need to be? it doesn't it only got to handle prompts, having an ArumentUsage handling that seems better and fresher as it is not a copy of any other framework arg systems it's Klasa's own still using the same usage strings as we always were. not many changes there this could also make it so much easier and cleaner to do arguments as we could now pass a RegExp as the type. We also allow the use of internationalization also known as i18n in prompts this making ArgumentUsage the most advanced Usage handling in a framework because Union types any other array based arg systems in other frameworks failed to add union types as it is too hard but ArgumentUsage makes union types still usable like before, now like I was saying this makes ArgumentUsage one of the best Usage/Arg systems in Discord.js Frameworks due to the fact how Powerful and Advanced it can be.

Suggestions / Ideas

paramName changed to id or key as paramName seems quite long just for an "id" or "key" as it is just the usage name for prompting and usage strings in help. Of course, it can be used in other cases tho

Add min and max while this could still be handled in type.

(Also sorry for bad grammar and English I have been awake for 25+ hours and i really CBA to think atm)

from klasa.

@MrJacz in the server we have many people who get errors because of usages. I myself took a while to figure out how the UsageDelim thing worked.

My point is: a total beginner will not understand the UsageString itself at first. They'll take some time, and figure it out. And then UsagePrompt won't be too hard, seeing it's so similar to permLevel.

And I'm against the argument usage idea because it seems unnecessary. As Kyra said, the current usageString is very good because it can be written in a jiffy. So much longer with the argument usage class. If both usage and that class are accepted, it's fine. But it seems unnecessary for just prompts.

@kyranet I imagine the UsagePrompt won't be able to handle union types then? (Different prompts for different types.)

from klasa.

my point being, my array way is ugly and Ao will most likely dislike something, undefined, next prompt here and UsagePrompt doesn't seem quite useful as if anything I feel as if you're going to add that you should just make a class to handle Usage as a whole yet usage should accept both ArgumentUsage and a regular usage string.
understanding how Usage and usage delim works takes time a couple of creating commands without help at least

from klasa.

Replying to @MrJacz

everything does the ArgumentUsage way looks very nice and advanced but will this suit for beginners? not really IMO while it is very advanced and would be powerful it could also be a hassle for beginners to understand

If you use an IDE with IntelliSense, it'll reveal the type and name for each parameter, making it substantially easier. And usageString isn't that easy to debug, however.

paramName changed to id or key as paramName seems quite long just for an "id" or "key" as it is just the usage name for prompting and usage strings in help.

In fact the correct and technical name is ArgumentName or ArgumentID, as Usage is understood as an array of arguments.

Add min and max while this could still be handled in type.

Using the current parser, this is possible. When type is typeof string, Klasa would use Tag.parseMembers() to parse the tags inside.

Replying to @soumil07

And I'm against the argument usage idea because it seems unnecessary. As Kyra said, the current usageString is very good because it can be written in a jiffy. So much longer with the argument usage class. If both usage and that class are accepted, it's fine. But it seems unnecessary for just prompts.

In fact ArgumentUsage has several additions:

1. Customizable prompts and i18n messages.
2. Better RegExp debugging. Of course, RegExp will always be valid as its misstyping would cause in JS to fail parsing it. And you can use your IDE and the syntax highlight to debug and read it even better.
3. Custom types. You need an argument type just for a single command? Pass a function. Done.
4. (Optional, depends on future implementation) You have an array of 23 possibles (for example, one for each hero in Overwatch)? You could "mask" them and show heroName.

And both usageString and ArgumentUsage are accepted, yes.

I imagine the UsagePrompt won't be able to handle union types then? (Different prompts for different types.)

That's not possible with UsagePrompt nor ArgumentUsage, in fact, it should keep one for each argument rather than one for each Tag.

from klasa.

Closed in favor of #162

from klasa.