This macro simply provides a easy singleton initializer for your command to allow for you do (if this class isn't the target of a command) to still be able to gather a Command object without having to have it as the target.

This will setup the default (no args) initializer to gather the handler from CliGen::App and then resolve all of the ivar (CliGen managed) to the parsed values from the associated Flag(T) object that (if the process itself is being started by CliGen the provided flags will store the value to be set here)

This macro is just meant to provide the user an ability to resolve instance var/varibles from parent commands. Simply to allow subcommands to be able to retrieve values from their parents

As an aside, this (as written) can only be used for variables that have a default defined (ex: @var : Int32 = 3)

For variables that (in your parent class) isn't set with a default value, you will need to provide the (default: ) kwarg to set your own runtime default if the value itself cannot be ensured by the compiler.

This is a requirement as this macro MUST always return a value without rasing, and the only way to do that is force the user to provide a default of their choosing.

This macro serves as a compile-time checker of the command-tree to validate that there is no recursive references of the command-list that would possibly cause a recursive stack-overflow during App.generate when App begins registering all user defined commands.

However, while this does exist, due to the way that the App.generate method handles gathering root commands it makes this edge-case impossible to hit aside from manually running the Command#register_command([] of CliGen::Command) method.

However, with this in place this issue cannot be hit at runtime as this will prevent compilation if a recursive/circular command tree exists.

Additionally, this exists to prevent the user from defining a command tree that extends past the compile-time configured max via the CliGen::MAX_COMMAND_DEPTH constant.

The reason this is a thing is because crystal macros don't allow for unbounded while's/until's in macros, meaning it always has to be deterministic. SO to deal with this and still allow for subcommand defining you need either go with the default (32 command depth) or define your own larger max (understand this will affect compile-time due to this directly affecting loops in the Command macros).