std.getopt suggestion

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Oct 6 07:24:06 PDT 2011


On 10/6/11 4:44 AM, Regan Heath wrote:
> On Wed, 05 Oct 2011 16:44:31 +0100, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 10/5/11 10:27 AM, Regan Heath wrote:
>>> I understand the issue, and the point you're making below, and I agree
>>> completely. At the same time, this particular change being as simple as
>>> it is, and as obviously beneficial as I hope I have managed to show,
>>> would have taken less time to simply change than it has taken to argue
>>> about.
>>
>> There is the issue that every small change creates a precedent for
>> similar or smaller changes. I spent this much time on this particular
>> issue hoping that it would improve an entire trend going forward.
>
> I think it may have backfired somewhat. Now people are going to think no
> change is possible and Andrei is an 'Ogre' when it comes to his own
> modules. In situations like this some sort of precedent or impression
> will always be created. The best you can do is take control of it, and
> clearly define it.
>
> In this case clearly define the conditions under which the change is
> allowed i.e.
> 1. The interface MUST not change (retaining the getopt free function for
> example)
> 2. The default behaviour MUST not change (retaining the current default
> values for the globals)
>
> and make that the precedent to enforce on future occasions. It should be
> like "common law", defined by the first instance, changed hesitantly and
> only for very good reasons.

It's a great thought, and definitely my image out there should not be 
that of an ogre! :o)

Problem here is, it's very difficult to come up with hard and fast 
rules, as inflexible rules tend to get used as justification for a 
variety of otherwise odd outcomes.

For example, it is possible to modify std.getopt to keep the existing 
interface unmodified and add a wrapper for the globals etc. Generally 
such constraints make the implementation (and often the interface) more 
difficult and convoluted, which in turn becomes a liability that must be 
justified by significant added value.

The only rule is, please use good judgment and focus on adding real and 
significant value, as opposed to shuffling the deck.


Andrei


More information about the Digitalmars-d mailing list