std.getopt suggestion

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Oct 5 15:41:45 PDT 2011


On 10/05/11 16:25, Nick Sabalausky wrote:
> "Andrei Alexandrescu"<SeeWebsiteForEmail at erdani.org>  wrote in message
> news:j6hrko$ni3$1 at digitalmars.com...
>> On 10/5/11 6:53 AM, Regan Heath wrote:
>>> On Tue, 04 Oct 2011 20:39:42 +0100, Andrei Alexandrescu
>>> <SeeWebsiteForEmail at erdani.org>  wrote:
>>>> Did it ever prevent you from getting anything done with it?
>>>
>>> That's not the question we should be asking. The question we should be
>>> asking is, will anyone ever want to re-use getopts parser for something
>>> other than a once off command line parse for a command line application.
>>
>> I don't think yours is the right question either. This thread has become
>> illustrative of a trend that would be great to change course a bit.
>
> I assume you're referring to the trend of being unsatisfied with unwavering
> single-person vetos on trivial-to-implement issues that have landslide
> support?

That would be a mistaken assumption.

>> I sustained my position in this thread longer than necessary in an
>> attempt to explain this to me and others.
>>
>> [snip big long story]
>
> In other words, there are many ways in which D's existing libs fail to be
> sufficient for people's uses.

Actually, it's about entire libraries that are missing. We don't "kind 
of" have a MySQL library. We just don't have one.

> Ummm, like getopt.
>
> Except getopt is easy low-hanging fruit.

There's low hanging fruit. And then there's low hanging berries, seeds, 
and spores.

>> other APIs that connect us to the world. The right question is, can we
>> afford to discuss packing three globals into one struct in std.getopt at
>> this time?
>>
>
> For god's sake, it would have taken less time to implement the fucking
> change (that nobody but you has been opposed to), than to write that little
> story about why we should ignore the matter.

I agree. That's not the point. (And relax.)

>> Making working code a tad better could go on forever, and might seem like
>> progress. But it's not - it's asymptotic progress towards a local optimum,
>> while we're looking at a hill of potential ahead.
>>
>> I kindly suggest anyone with an interest in D's future to focus on moving
>> the big rocks. We can worry about the gravel and the sand later.
>>
>
> Not to be an ass, but even *I* don't think reviewing and getting outdent
> whipped into shape was a "big rock" or anything bigger than gravel. (Though
> I am very appreciative of it and I'm very happy with the final result.)

I'm happy too. Although it entailed essentially as much work from me as 
a full-fledged implementation (actually a tad more), it's a good outcome 
because (a) it adds genuine new functionality, (b) it sets up the stage 
for more new things in the future from you and others.


Andrei


More information about the Digitalmars-d mailing list