obsolete D libraries/modules

[H. S. Teoh]

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.


> 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.


T

-- 
Meat: euphemism for dead animal. -- Flora