std.getopt suggestion

Walter Bright newshound2 at digitalmars.com
Tue Oct 4 02:02:06 PDT 2011


On 10/4/2011 1:06 AM, Nick Sabalausky wrote:
> "Walter Bright"<newshound2 at digitalmars.com>  wrote in message
> news:j6e1k9$2p9u$1 at digitalmars.com...
>>
>> 2. Once a feature is there, it stays forever. It's very hard to judge how
>> many people rely on a feature that turns out in hindsight to be baggage.
>
> If people are relying on it, is it really baggage?

Yes.

The C++0x Committee attempted to dump support for trigraphs. I read the adamant 
ripostes to that proposal from a very small handful of users. Those users' 
arguments were flat out wrong (in my not-so-humble opinion) and there is an 
obvious, easy workaround for their old code. But they still carried the day, and 
trigraphs stayed in, still wreaking havoc.

I'm not willing to go as far as C++ in maintaining compatibility with 
misfeatures, but there's no denying the success it has had with that approach.


>> It's why I have rather bull-headedly resisted adding feature after feature
>> to D's unittest facility. The unittest feature has been a home run for D,
>> and I suspect a lot of its success has been its no-brainer simplicity and
>> focus on doing one thing well.
>
> What makes D's unittests attractive is the simplicity of the
> minimal-while-still-being-useful case, and *not* it's limitations. The
> general guiding principle of making the typical cases simple and the
> advances cases possible is one of the primary things that makes D fantastic.
> Unittest's approach of making the typical cases simple and ignoring advanced
> cases smacks of Jobs-ian arrogance and stands in contrast to normal D
> principles. (Again, Jobs is to be reviled, not revered.)

I don't agree that the advanced cases are impossible with D. They just are not 
built-in, and one will need to do a bit of extra work to do them.


More information about the Digitalmars-d mailing list