Arbitrary abbreviations in phobos considered ridiculous

[Nick Sabalausky]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.366.1331335812.4860.digitalmars-d at puremagic.com...
> On Friday, March 09, 2012 16:16:56 Brad Anderson wrote:
>> On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis 
>> <jmdavisProg at gmx.com>wrote:
>> > On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote:
>> > > I'll say I *don't* agree with the rejection of aliases on 
>> > > principle --
>> > > aliases can be extremely useful/helpful, and they cost literally 
>> > > nothing
>> > > (the "cognitive cost" on the docs is a BS argument IMO). I just don't
>> > > agree with consuming so many common symbols for the sake of sugar.
>> >
>> > aliases need to have a really good argument for existing. If UFCS is 
>> > fully
>> > implemented, then I think that there is _some_ argument for having 
>> > stuff
>> > like
>> > hours and minutes, because then you can do stuff like 5.seconds() 
>> > (though
>> > honestly, I really don't like the idea). The alias enables different
>> > usages
>> > rather than simply being another name for the same thing.
>> >
>> > Now, in this particular case, it's that much worse for exactly the 
>> > reason
>> > that
>> > you're against it: it uses common names for free functions. It's not as
>> > big a
>> > problem as it would be in C or C++, but it's still a problem. There's 
>> > also
>> > some risk that it will break code.
>>
>> Oh, and I'd just like to add some of my experience to this. These names 
>> are
>> used by Boost's datetime library and they've never been a problem for me
>> and at work we make extensive use of Boost datetime. There is risk but I
>> think in this specific case they are fairly small (especially in D, over
>> C++). We switched to Boost datetime after we had hundreds of thousands of
>> lines of code written using a different system and I didn't encounter any
>> problems with the duration shortcut functions clashing.
>>
>> Anyway, it sounds like Walter is probably opposed from what he was saying
>> in the other thread so this conversation is probably moot.
>
> I'd say that there's a higher chance of the aliases being added than of 
> dur
> being changed to duration. Changing dur will _definitely_ break code and 
> make
> using it worse for exactly the same reason that it's dur in the first 
> place -
> it's too long when combined with the required units string. The aliases 
> might
> break code, but it's probably only in cases where someone already has free
> functions with those names, and it's more likely that they'll have 
> variables
> with those names, which are less likely to conflict.
>
> So, while I don't really like the idea of adding the aliases, they _might_ 
> be
> added, because they probably won't break anything, and they enable UFCS. 
> But
> there's not a good enough reason to change dur to duration at this point.
>

They eliminate the *entire* reason for it ever even being "dur" in the first 
place.

Of course, if this incarnation of std.datetime were a few years old, then 
I'd likely agree with you, but it *is* still relatively new.