Re: argparse version 0.7.0 - a CLI parsing library
On Thursday, 17 March 2022 at 19:07:28 UTC, H. S. Teoh wrote:
Using independent, orthogonal UDAs may make option
specification using your module easier to read. For example,
from your docs:
struct T {
@(NamedArgument
.PreValidation!((string s) { return s.length > 1 && s[0] ==
'!'; })
.Parse!((string s) { return s[1]; })
.Validation !((char v) { return v >= '0' && v <= '9';
})
.Action !((ref int a, char v) { a = v - '0'; })
)
int a;
}
could be rewritten with multiple UDAs as:
struct T {
@NamedArgument
@PreValidation!((string s) { return s.length > 1 && s[0] ==
'!'; })
@Parse!((string s) { return s[1]; })
@Validation !((char v) { return v >= '0' && v <= '9'; })
@Action!((ref int a, char v) { a = v - '0'; })
int a;
}
It might also simplify your implementation by having more
smaller, independent pieces for each UDA instead of a single
complex UDA that handles everything.
I use UDAs extensively in my project and I've historically been
doing the multiple-UDA approach you describe. Upon seeing
argparse a few months back I started rewriting it to use a single
UDA, and I found it allowed for a simpler implementation (and not
the other way around).
The immediate gains boiled down to that I could now pass what is
essentially a context struct around at CTFE instead of keeping
track of multiple variables. Default values are also much easier
to manage with much fewer `hasUDA`s sprinkled everywhere.
One drawback is documentation; adrdox does *not* like these kinds
of UDAs.
Re: argparse version 0.7.0 - a CLI parsing library
On Friday, 18 March 2022 at 18:21:46 UTC, Anonymouse wrote: One drawback is documentation; adrdox does *not* like these kinds of UDAs. It is on my list to run big UDAs through the auto-formatter at some point pretty soon to help with this. I just have a big work project I'm wrapping up first.
Re: argparse version 0.7.0 - a CLI parsing library
On Friday, 18 March 2022 at 19:09:27 UTC, Adam D Ruppe wrote: On Friday, 18 March 2022 at 18:21:46 UTC, Anonymouse wrote: One drawback is documentation; adrdox does *not* like these kinds of UDAs. It is on my list to run big UDAs through the auto-formatter at some point pretty soon to help with this. I just have a big work project I'm wrapping up first. Sweet!
Re: argparse version 0.7.0 - a CLI parsing library
On Fri, Mar 18, 2022 at 06:21:46PM +, Anonymouse via Digitalmars-d-announce wrote: > On Thursday, 17 March 2022 at 19:07:28 UTC, H. S. Teoh wrote: > > Using independent, orthogonal UDAs may make option specification > > using your module easier to read. For example, from your docs: [...] > > It might also simplify your implementation by having more smaller, > > independent pieces for each UDA instead of a single complex UDA that > > handles everything. > > I use UDAs extensively in my project and I've historically been doing > the multiple-UDA approach you describe. Upon seeing argparse a few > months back I started rewriting it to use a single UDA, and I found it > allowed for a simpler implementation (and not the other way around). > > The immediate gains boiled down to that I could now pass what is > essentially a context struct around at CTFE instead of keeping track > of multiple variables. Default values are also much easier to manage > with much fewer `hasUDA`s sprinkled everywhere. Hmm, interesting indeed! I should experiment with both approaches to do a fairer comparison. T -- Век живи - век учись. А дураком помрёшь.
Re: argparse version 0.7.0 - a CLI parsing library
On Friday, 18 March 2022 at 18:21:46 UTC, Anonymouse wrote: I use UDAs extensively in my project and I've historically been doing the multiple-UDA approach you describe. Upon seeing argparse a few months back I started rewriting it to use a single UDA, and I found it allowed for a simpler implementation (and not the other way around). The immediate gains boiled down to that I could now pass what is essentially a context struct around at CTFE instead of keeping track of multiple variables. Default values are also much easier to manage with much fewer `hasUDA`s sprinkled everywhere. One approach you might consider is a hybrid too, where you have the big struct you build out of the individual udas. So you work on the big one but you do getBig!decl and it loops through the members of thebig struct and sees if the same-typed UDAs are on decl. If so, it loads them in, if not, it leaves default values. Then the user can write it either way and you always process it simpler.
Re: argparse version 0.7.0 - a CLI parsing library
On Fri, Mar 18, 2022 at 09:30:57PM +, Adam Ruppe via Digitalmars-d-announce
wrote:
[...]
> One approach you might consider is a hybrid too, where you have the
> big struct you build out of the individual udas.
>
> So you work on the big one but you do getBig!decl and it loops through
> the members of thebig struct and sees if the same-typed UDAs are on
> decl. If so, it loads them in, if not, it leaves default values.
[...]
Yeah, that's what I thought too. So you could have something like this:
struct SmallUDA {}
struct AnotherSmallUDA {}
struct AggregateUDAs {
bool hasSmall;
bool hasAnotherSmall;
static typeof(this) opCall(T)() {
AggregateUDAs result;
hasSmall = hasUDA!(T, SmallUDA);
hasAnotherSmall = hasUDA!(T, AnotherSmallUDA);
return result;
}
}
void processUDAs(T)() {
// Look ma! No need to sprinkle hasUDA everywhere
enum aggreg = AggregateUDAs!T();
...
static if (aggreg.hasSmall) { ... }
...
static if (aggreg.hasAnotherSmall) { ... }
...
}
@SmallUDA
@AnotherSmallUDA
struct MyInputType { ... }
processUDAs!MyInputType();
T
--
Why did the mathematician reinvent the square wheel? Because he wanted to
drive smoothly over an inverted catenary road.
Re: RESCHEDULED - Silicon Valley D Meetup - March 18, 2022 - "D's new ImportC for easier C library usage"
On 3/17/22 07:25, matheus wrote: > Any chance this will be available for watch later? As always, it wasn't in presentation style; rather, my pointing at what is possible in source code. I will write something up and make example code available. Ali
