search

akamensky / argparse

Argparse for golang. Just because `flag` sucks
MIT License
604 stars 62 forks source link

testFunction #56

Closed goofinator closed 3 years ago

goofinator commented 4 years ago

I thought it would be nice to include a test function in the options. If it is defined, when creating the argument, you should test the received value of the argument with its help. If it fails, finish processing with an error. This will help the user to handle a wide range of situations when the list of values ​​is limited, not providing for all cases in the library itself.

akamensky commented 4 years ago

There are validation functions already, where developer can provide own validators. I.e. validate that string is URL, or a valid email address.

Is this the same? If not, what is different from what you are proposing here?

akamensky commented 4 years ago

See Options.Validate at https://github.com/akamensky/argparse/blob/master/argparse.go#L95

goofinator commented 4 years ago

Yes. I apologize - did not notice. However, it confuses me that the validator checks the original parameter string. It may make sense to validate the final value, i.e. pass interface {}.

akamensky commented 4 years ago

The idea behind this approach was that validators should be very reliable (and I don't see type casting from interface as reliable, it is prone to human errors).

Originally I planned to provide a set of pre-defined validators (i.e. checking that string is a valid email address), but did not get to implementing that. This could reduce the need for manual implementation of those validators, and the fact that it takes a string would be less bothering.

It would possibly be okay to change argument to interface and pass already parsed value type. However at this stage it would constitute a behavior change, which is a problem.

I think there are two options to go about that:

goofinator commented 4 years ago

Ok. So, it's better to leave this issue here as reminder?

akamensky commented 4 years ago

Probably good idea to have a list of items for v2. I.e. wiki page, or a text/markdown document in this repo.

goofinator commented 4 years ago

I think it is worthwhile to work out some goals for the moment to define further development. It is time to introduce such things as narg, position arguments, maybe exclusive groups of arguments. But before you implement this in code, it would be nice to understand exactly what it should look like for the user to make it clear and convenient, without looking back at how it should be implemented.

It can be done in the same way as in the Go repository: https://github.com/golang/proposal/ When the critical mass of design wishes, incompatible with the current major version, will be established - the v2 folder could be created. May be it would be better to keep all about v2 in separate branch (the v2 folder and modification of mod file) for now. Or some thing. Honestly, I have no big experience of working with go modules versions of v2+.

akamensky commented 4 years ago

The changes for v2 sure should go to v2 branch as intended when using go modules.

What I meant is a place to keep a list of suggestions/proposals for v2. Either a separate ticket which would link to all other tickets. Or milestone in issues. Or a text file. Either is fine I think.

goofinator commented 4 years ago

ok. I think it's good. May be a separate issues tag should be highlighted for this file?

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon if no further activity occurs. Thank you for your contributions. Feel free to comment or otherwise update to keep it alive.

stale[bot] commented 3 years ago

Closing due to old age. Feel free to re-open or ping maintainers.