obsolete D libraries/modules

[Jonathan M Davis]

On Sunday, September 01, 2013 22:32:34 H. S. Teoh wrote:
> On Sat, Aug 31, 2013 at 07:29:42PM -0700, Jonathan M Davis wrote:
> > On Saturday, August 31, 2013 19:18:11 Andrei Alexandrescu wrote:
> > > I remember sitting next to Kirk McDonald at the D conference in 2007
> > > as he was showing me Python's argparse. I personally found pretty
> > > much any example we could think of more verbose and uglier than
> > > std.getopt.
> > 
> > std.getopt is definitely lacking some nice-to-have features (like
> > automatically generating --help from the options), but for the most
> > part, I don't think that it can be improved much without seriously
> > complicating it. I think that it's about at the limit of what can be
> > done and still have it be simple, and it works really well for the
> > most part, so if we haven't hit the sweet spot, we're at least close.
> > I've toyed with trying to figure out how to improve it, but I think
> > that doing so cleanly would be very hard.
> 
> I've had several people complain to me about std.getopt not
> understanding / supporting "standard" command-line syntax. Like '-c5'
> vs. '-c 5'. I've also experienced some quirks in how it handles option
> parsing, such as being unable to distinguish between '-w' and '--water'
> where both are distinct options (the use case is that multiple options
> begin with 'w', but one is more common than the others so '-w' is
> desirable as a shorthand, but currently std.getopt support for this is
> sketchy and unreliable).
> 
> I'm not sure how to address this issue, though; I assume some of the
> design decisions stemmed from Windows vs. Posix compatibility, which may
> make supporting this kind of syntax tricky to support.

Some of its defaults are definitely wrong (e.g. bundling should be the default 
so that -water is identical to -w -a -t -e -r), but those are minor design 
flaws that could be fixed quite easily without really changing the API (though 
fixing some of them would change behavior enough that it would change the 
behavior of current code in a silent manner that might tick off some 
developers). If we were to have to create a new function to fix any of getopt's 
problems (e.g. the exception types that it throws), then I would want to fix 
some of getopt's defaults.

If we had a nice list of getopt's quirks that should arguably be fixed, then we 
can look at creating a getOpt function with the improved behavior, but I think 
that that's very different from actually coming up with a new API, which is 
what would be required for some of the changes that some people want (like 
automatically generating --help), and that's what I think would be quite 
difficult to do cleanly. What we have is very close to ideal IMHO. It just needs 
a few tweaks.

> > The main thing that I'd really like to see changed is the exception
> > types that it throws, because I'd very much like to be able to have
> > code which can give specific information about how the flags were
> > incorrectly used and whatnot, and ConvException (which is usually what
> > you get) doesn't cut it for that. You'd need getopt-specific
> > exceptions for that. But we can fix that without changing the API.
> > It's just that doing so would likely break code which was catching
> > ConvException explicitly, so if we do that, we might be forced to
> > introduce getOpt to replace getopt or something like that. But even if
> > we did that, the basic design wouldn't change, just what it's throwing
> > on failure.
> 
> [...]
> 
> Ideally, getopt should catch ConvExceptions (and whatever other
> exceptions that get thrown when a conversion fails, e.g., from a
> user-supplied delegate) and rethrow it with a better message. For
> example, "unable to convert 'abc' to int in option '-a'" instead of
> "std.exception.convException: illegal digit" or something similarly
> obscure, which is completely unhelpful to the end user.

The message really isn't enough. I need to be able to programatically deal 
with the the error, meaning that I have to know things like exactly which flag 
failed. I may or may not have any interest in what the ConvException said. 
Having a nicer message for a GetOptException would be nice, but that would 
just be a bonus as far as I'm concerned.

- Jonathan M Davis