Thoughts on a Lists

[goofinator]

There is a question. There are arguments with a parameter for different types (String, Float, Int). There is also an argument of type List, which allows you to create a list of parameters of type String. Wouldn't it be logical to make StringList, FloatList, IntList?

[akamensky]

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.

[goofinator]

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.

[akamensky]

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.

[goofinator]

OK

[akamensky]

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

[goofinator]

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

[akamensky]

Sure

[akamensky]

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