Parameters usability

[RomanZhu]

I find current 'CommandArg[]' approach quite daunting, 'cose I am generating commands out of some other code and it should support different types like Vector3, Сolor, enums, etc.

It would be cool to have something like ReflexCLI way of doing things. So we can provide custom types
http://reflex.richardmeredith.net/documentation/index.php?title=Parameter_Processors

And it's possible to have commands like this:

    [ConsoleCommand]
    static int MultiplyAndFloor(float a, float b)

Which is ideal for usability, no workarounds needed

[stillwwater]

This is done for performance. If all commands have the same signature they can be stored as Action<CommandArg[]> objects, this way the methods can be called with comparable overhead to calling them directly in C#.

Allowing different signatures would require the command methods to be stored as MethodInfo objects and be invoked at run-time with reflection, which is significantly slower than the delegate version (~20x slower in my testing).

I figured the readability trade off was worth it for the performance gains. Letting the arguments be parsed in the command method lets you parse types of Vector3, Color, etc. on your front end code, instead of having a parser that accounts for every type people would want to use.

I really wanted to have proper parameters in commands like in your example, but I don't see a way to do it that doesn't compromise performance, or accounts for custom types.

[JimmyCushnie]

Although invoking a MethodInfo is much slower than an Action<CommandArg[]>, I'm not sure the performance difference is really relevant for this situation. Computers are just so fast that the user won't ever notice the difference.

Your points about standardizing parsing logic for command input are very good, however.