set the channel description: In case people want to respond to my request for feedback about Karg, but don't want to spam general https://github.com/jshmrsn/karg

I just realized you can use references to constructors as lambda inputs. This actually makes Karg's API usage a little nicer looking.

parseArguments(args, { ExampleArguments(it) })

is now

parseArguments(args, ::ExampleArguments)

Joshua, why the specified avoidance of reflection in the docs, not sure why reflection would or would not be needed, but what's the issue if so? It's one time command line parsing, a few classes, and not android, so why the avoidance?

The same thing for type safety and nullability, unless you have a huge command line parsing tree, those things affect 0.01% of total code in the app when dealing with command line parsing.

So unless you cover every feature of the "other" libraries you lose - - by having fewer benefits.

It might have been possible to get the same with a tweak or extension to an existing lib, as a faster way to the finish line on this project.

But, if you continue and so get to the finish line... If you want we could add this under kohesive libs, or klutter. And do the maven central publishing under that name space, and that channel slack channel. Let me know.

@apatrida: for one thing I like libs without reflection because one can clearly see their implementation by their code. Reduces the need for docs\conventions. That is a reason for me to choose a library, don't know about @jshmrsn

Reflection is just code too. But was more curious about the authors viewpoint since he made a point of it in the readme. I understand viewpoints for reflection or not, just wasn't sure why it applied here to this lib.

Wanting to understand his design choice.

what are the advantages of karg over commons-cli? I've been using it in a project without any issues regarding safety

Thanks for the questions! I'm going to respond to both since they are ultimately related. I am a fan of argument parsing libraries that leverage class definitions to add compile time checks around the command line option definitions and the code that reads the provided values for those options. @simonorono In this sense, I do not like commons-cli's approach. There's a single Option class that can represent any kind of option, so there's no compile time checks around the option value's type or optionality. @cedric's JCommander is a parsing library that is closer to what I am looking for. It uses class definitions and annotations to specify options. However, I personally wasn't quite satisfied with it for use in Kotlin because its API relies on the class member properties being mutable and either nullable or have a default value specified. This doesn't play nicely with Kotlin's nullability semantics, where a required value should be non-nullable, and a nullable value should ideally be immutable so that it can be smart-casted to non-nullable. @apatrida This is where reflection comes in. Certainly everything is just code under the hood, but the problem with reflection is that the compiler cannot follow the logic executed through reflection. So, if a class's properties are initialized solely through reflection, the Kotlin compiler will not know that the values are initialized, and complain that the class properties must have values assigned to them in the constructor, or be lateinit, etc.. This is why I took the approach in Karg of having the provided argument values actually be returned from the functions that declare the the option. This enables initialization to happen right in the constructor (or initial property values), which plays very nicely with Kotlin's type system and nullability guarantees. As @voddan pointed out, reflection can lead to library-specific conventions that aren't compiler enforced, potentially less straightforward code, etc.. In Java land, it also seems that use of reflection often means using an additional reflection library (dependency), since the vanilla Java reflection APIs don't provide simple solutions for common use cases. That's why I included "no reflection" and "no dependencies" on the same line in the readme. In regards to command line argument parsing being 0.01% of total code. On my side, Karg is part of a larger effort to build a Kotlin development environment that can be used to quickly write many utility scripts. Specifically, I'm replacing dozens of small-to-medium Ruby/Python/Pearl/Bash scripts with type-safe and structured Kotlin, each with their own cli argument definitions. The goal of this effort is to make my large collection of scripts (which add up to decent sized codebase of their own) more maintainable in the long run. That maintainability is hoped to come in part from a more structured and type safe representation of the command line arguments.

<!here|@here> Pushed "Added support for explicitly defining positional argument with a name, description, min and max counts. Added positional arguments info to help text generation." Sadly, positional arguments must be defined after all other arguments, which goes against my previous statement about "library-specific conventions that aren't compiler enforced". Hopefully there's a better solution, but I haven't thought of one yet

-.kt

@surya has left the channel

hi joshua, any thought about pushing karg into maven?

@marcusti has left the channel

@eduardokolomajr has left the channel

@chansek has left the channel

@mesquka has left the channel

@surya has left the channel