Thoughts on a Lists about argparse HOT 8 CLOSED

Yes, it absolutely would. I initially implemented those that were most commonly used, however there are many more possible argument types to add I believe. There is also a question of positional arguments (see #38 discussion) which could expand into having its own list of types etc.

from argparse.

I think that moving from List to TypeList would make semantics more explicit and
less controversial.
For a few common types - not so mach work, at first glance.

If there is a fear that the number of parameter types or argument types will increase, then it may make sense to separate argument types and data types of their parameters.
For example:
type DataType int
const (
StringType DataType = iota// string - is default
IntType
FloatType
FileType
// et c.
)
func ArgumentSingle(typeToUse DataType,...) DataType{...}
func ArgumentsList(typeToUse DataType,...) DataType{...}
func ArgumentsN(typeToUse DataType,...) DataType{...}
func ArgumentsFinalList(typeToUse DataType,...) DataType{...}
//et c.
or maybe even better:
func (typeToUse DataType) ArgumentSingle(...) DataType{...}
//--//--

But this approach will be ... harder to implement. What can I say.

As for ease of use, I don’t know ... on the one hand, it is necessary to print an additional parameter each time an argument is generated, on the other hand, the number of combinations drops sharply.

from argparse.

I don't think the number of methods is an issue, while number of arguments to methods is. I think separate methods (IntList, FloatList etc) makes more sense here rather than passing type to the methods as an argument (also method should return a specific type of pointer, common method that accept multiple types can only return interface then, which does not really help developer).

I think as with other methods in this library as long as implementation is easy to use -- it will be fine. After all the goal here is to simplify life of developers.

In which case my preference is more towards separate methods for each type (i.e. Int, String for singular + IntList, StringList for lists).

Also for backward compatibility would still need to preserve current List method, which can be an alias to StringList. It can be perhaps removed if/when there would be v2 version of this library.

from argparse.

OK

from argparse.

@goofinator should this be closed now? Or there are still more relevant changes coming?

from argparse.

i think that's all, here. Except some documentation. May be i should append some thing on it in the readme?

from argparse.

Sure

from argparse.

Feel free to close this issue whenever you think it is done.

from argparse.