Arbitrary abbreviations in phobos considered ridiculous

Nick Sabalausky a at a.a
Fri Mar 9 13:49:31 PST 2012


"Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message 
news:op.waxaa1s1eav7ka at localhost.localdomain...
> On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky <a at a.a> wrote:
>
>> "Nick Sabalausky" <a at a.a> wrote in message
>> news:jj6gjm$2m6a$1 at digitalmars.com...
>>>
>>> But, I'm thinking this whole "dur vs duration" matter is stupid anyway.
>>> Seconds, hours, etc *are* durations. What the hell do we even need the
>>> "dur" or "duration" for anyway?
>>>
>>> I say fuck it: Let's just toss this into core.time (or std.datetime or
>>> whatever) and be done:
>>>
>>> alias dur!"years" years;
>>> alias dur!"months" months;
>>> alias dur!"weeks" weeks;
>>> alias dur!"days" days;
>>> alias dur!"hours" hours;
>>> alias dur!"minutes" minutes;
>>> alias dur!"seconds" seconds;
>>> alias dur!"msecs" msecs;
>>> alias dur!"usecs" usecs;
>>> alias dur!"hnsecs" hnsecs;
>>>
>>> And then we have the brevity issue solved (and in fact, improved over
>>> "dur"), so then "dur" can (and should) change to "duration" without
>>> screwing up brevity. And all probelms are optimally solved. As for the
>>> possibility of new name collisions: Honestly, in this case I see no 
>>> reason
>>> to give a shit.
>>>
>>
>> https://github.com/D-Programming-Language/druntime/pull/174
>>
>> https://github.com/D-Programming-Language/phobos/pull/485
>>
>> https://github.com/D-Programming-Language/tools/pull/23
>>
>> I completely understand the "secs==seconds" pull request being rejected 
>> and
>> I think that's perfectly reasonable...
>>
>> But I'm going to be really pissed if this one's rejected out of some
>> misapplied, overly-puritanical obsession with "no aliases".
>
> You'll need to have dur aliased to duration to follow the normal 
> deprecation procedure.
>

Yea, I already have that in there. (I was going to link to the line in the 
diff, but github's being it's usual steaming piece of shit again...)

> I can't say I agree with this, as it pollutes the global namespace with 
> several common terms that could be used for fields.
>

I'd argue that should not be considered a problem in this case:
http://forum.dlang.org/post/jj6hnv$2o9s$1@digitalmars.com




More information about the Digitalmars-d mailing list