On 10/13/21 7:36 PM, Andrey Zherikov wrote:
On Wednesday, 13 October 2021 at 16:24:52 UTC, Steven Schveighoffer wrote:
The point is that I shouldn't have to tell the library the name of
something that I've already given a name to.
Having them named differently on the command line than the actual
field name should still be a possibility (and required in some cases,
e.g. the `enum` case above), but honestly, the `Params` struct exists
solely to accept command line parameters, there's no compelling need
to use alternate names for the command line and the field name. If the
library automatically does the right thing by default, then your code
becomes simpler and more beautiful.
Not to detract from your library, because I think it's an awesome
design to model using structs (one I use all the time), but the API
developer in me frowns at lack of DRY. Try to focus on requiring the
smallest amount of machinery/attributes possible. Every time you
require extraneous pieces to get things to work, it adds another place
where errors/confusion can happen.
I got your point. Omitting the name is good suggestion and I'll add this.
Regarding the detecting all members and treating them as an arguments, I
see one issues so far: the struct might have other members that are not
used in CLI (it can be even functions).
Having done a lot of stuff with serialization and UDAs, this turns into
a mess if you have multiple systems (serialization is really what you
are doing here) using the same structs. So really, you are likely to
have this `Params` struct be distinctly for parameter parsing. It's OK
to have requirements such as expecting all items to be serialized by
default and in a default way.
Consider the example when the member is renamed but the struct still
provides the old name for backward compatibility:
```d
struct T
{
string name;
@property string label() const { return name; }
}
pragma(msg, __traits(allMembers, T)); // tuple("name", "label")
```
Various ways to solve this:
1. Have an `@ignore` uda
2. UFCS `label`
3. make `label` private (and ensure you check for that in your library code)
So to implement your suggestion correctly, `argparse` should provide a
way to opt-out specific members from CLI.
Possibly. Another possibility is to use WebFreak's idea and just tag
them with `@NamedArgument` without a name, then you can opt-in via
`@NamedArgument:` at the top (or put in a scope).
The way I approach serialization is "how would I serialize this thing if
I wrote the code manually?" and use that as the default implementation.
Then if you want to do things different from the default, use UDAs for that.
In addition to that, each CLI argument usually has its own help text so
in most cases each member will have an UDA with this text which makes
opt-out approach mush less useful. So it sill look like this at the end:
```d
struct T
{
@help("First name")
string firstName;
@help("Last name")
string lastName;
@skip
@property string fullName() const { return firstName~" "~lastName; }
}
```
It's not the UDAs, it's requiring in the UDA a repeat of the name that's
already introspectable. I also prefer having a default handling for
something so UDAs are not needed, but this is not as important.
Also, I'll note for your example, having an explanation for "firstName"
to mean "First Name" is another thing that reasonable people can
disagree on, but IMO, I would just let the name speak for itself.
-Steve
