March 07, 2012
"Derek" <ddparnell@bigpond.com> wrote in message news:op.warmsnem34mv3i@red-beast...
> On Wed, 07 Mar 2012 03:38:09 +1100, Adam D. Ruppe <destructionator@gmail.com> wrote:
>
>> Why aren't we using real words here? Real words are easier to remember and easier to type.
>
> Should we use American or English spelling? Color verses Colour, for example?
>
>
> -- 
> Derek Parnell
> Melbourne, Australia

American.  Always.


March 07, 2012
On 07.03.2012 6:18, Nick Sabalausky wrote:
> "Jonathan M Davis"<jmdavisProg@gmx.com>  wrote in message
> news:mailman.110.1331077432.4860.digitalmars-d@puremagic.com...
>> On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote:
>>>
>>> Nope, apparently, I meant "dur". Ridiculous.
>>
>> A Duration needs to be constructed with a template, and
>> duration!"hours"(13),
>> duration!"seconds"(44), etc. is painfully long when used in expressions.
>> So,
>> it was shortened to dur. I don't know of any other abbreviation which
>> would
>> make sense.
>>
>
> This is exactly why "dur" never bothered me. Now that Adam's brought it up,
> I can see how it can be considered bad, but at the same time
> 'duration!"seconds"(44)' is a rather long to way to refer to x number of
> seconds.
>
> 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.
>
>

+111
By the way name collisions are not that bad, I mean one still can have say hours variable an it still going to work. At least the following works with std.regex:

auto match = match("abc", "abc");
if(match)
	writeln("Wow!");

Probably it won't work if one have match func with 0 arguments.

-- 
Dmitry Olshansky
March 07, 2012
On 2012-03-07 01:01, Ary Manzana wrote:
> On 3/6/12 8:58 PM, Ary Manzana wrote:
>> On 3/6/12 8:43 PM, Jonathan M Davis wrote:
>>> On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote:
>>>> writeln(time.toISOExtendedString()); // bzzt, wrong, but this
>>>> used to work!
>>>
>>> Yes, and it was quickly changed to toISOExtString, because
>>> toISOExtendedString
>>> is painfully long. toISOExtString is bad enough, but you can't really
>>> make it
>>> any shorter without making the name uninformative.
>>>
>>>> Nope, apparently, I meant "dur". Ridiculous.
>>>
>>> A Duration needs to be constructed with a template, and
>>> duration!"hours"(13),
>>> duration!"seconds"(44), etc. is painfully long when used in
>>> expressions. So,
>>> it was shortened to dur. I don't know of any other abbreviation which
>>> would
>>> make sense.
>>
>> Painfully long?
>>
>> How much time does it take you to type 5 more chars? How much time does
>> it take you to understand "dur" when you read it instead of "duration"?
>
> Also, it becomes long because it has a weird syntax, that either way is
> going to be hard to read. In Ruby (with active support) I can just do:
>
> 44.seconds
>
> Why D doesn't do the same if it has UFCS? (I hope I got the acronym well)

Yeah, time and dates are ridicules easy in Ruby with active support. Say I want the date from two weeks ago, I just say that:

a = 2.weeks.ago

Super easy.

-- 
/Jacob Carlborg
March 07, 2012
On 2012-03-07 03:18, Nick Sabalausky wrote:
> "Jonathan M Davis"<jmdavisProg@gmx.com>  wrote in message
> news:mailman.110.1331077432.4860.digitalmars-d@puremagic.com...
>> On Tuesday, March 06, 2012 17:38:09 Adam D. Ruppe wrote:
>>>
>>> Nope, apparently, I meant "dur". Ridiculous.
>>
>> A Duration needs to be constructed with a template, and
>> duration!"hours"(13),
>> duration!"seconds"(44), etc. is painfully long when used in expressions.
>> So,
>> it was shortened to dur. I don't know of any other abbreviation which
>> would
>> make sense.
>>
>
> This is exactly why "dur" never bothered me. Now that Adam's brought it up,
> I can see how it can be considered bad, but at the same time
> 'duration!"seconds"(44)' is a rather long to way to refer to x number of
> seconds.
>
> 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.

I agree, adding these aliases would be a good idea.

-- 
/Jacob Carlborg
March 07, 2012
On 2012-03-07 04:46, Nick Sabalausky wrote:
> "Adam D. Ruppe"<destructionator@gmail.com>  wrote in message
> news:bwqkuqhyiygvgqswicvz@forum.dlang.org...
>> On Wednesday, 7 March 2012 at 03:24:23 UTC, Jonathan M Davis wrote:
>>> I don't understand this complaint at all. curr is an incredibly common
>>> abbreviation for current.
>>
>> Is it your *first* choice?
>
> In the general case, it frequently is for me. In the specific case of
> Clock.curr(ent)?Time, I'm equally happy either way. Although I agree with
> whoever it was (Brad?) that said "Clock.now()" would be even better.
>
>

Yeah, Clock.now() would be good and Data.today() as well.

-- 
/Jacob Carlborg
March 07, 2012
On 03/06/2012 10:30 PM, deadalnix wrote:
>
> auto helps too.

This remark was explicitly about _Java_ code style.
March 07, 2012
On 06/03/2012 18:49, Nick Sabalausky wrote:
<snip>
> Five times quantity seven plus three end of quantity
>
> Look! It's just normal English! And the editor can highlight it properly! No
> need to remember arbitrary symbols that aren't spelled-out! I mean, shit,
> how does a vertical and horizontal line mean "plus"? I can't remember that!
<snip>

There's another esolang idea - no symbols to have to remember, you have to spell everything out.

OK, so maybe it's already been done (COBOL, and to some extent SQL).

Stewart.
March 07, 2012
On 06/03/2012 20:20, Derek wrote:
<snip>
> Should we use American or English spelling? Color verses Colour, for example?

Make one an alias of the other.

Stewart.
March 07, 2012
On Tue, 06 Mar 2012 11:38:09 -0500, Adam D. Ruppe <destructionator@gmail.com> wrote:

> One of the stumbling blocks on using std.datetime is how
> many bizarre abbreviations it has.
>
> auto time = Clock.currentTime(); // bzzt, wrong

I would have guessed Clock.now();

> if(time - something > duration!"hours"(4)) // bzzt, wrong

I would have guessed Duration.hours(4);

>
> writeln(time.toISOExtendedString()); // bzzt, wrong, but this used to work!

I would have looked this one up regardless :)

> Why aren't we using real words here? Real words are easier
> to remember and easier to type.

First, it doesn't matter what you pick.  People have their expectations, and nobody has the same ones.  It's all about learning the library and getting used to what is there.

Second, I agree that to abbreviate a couple characters is somewhat petty.

Third, I don't think any of the names in datetime are horrible.  dur!"seconds" is immediately clear what it means.

Fourth, I kind of like having names that aren't going to be common field names.  For example, duration may be a common field that I would put in some kind of timer object.

You could make the same argument against dup vs. duplicate, or writeln vs. writeLine, I could go on forever.  There are no perfect names, because everyone has a different opinion.

> And the dmd spellchecker doesn't always help:
>
> Error: template instance duration!("hours") template 'duration' is not defined, did you mean Duration?

This is a red herring.  The spellchecker cannot possibly know what you meant unless you were only a couple characters off.  It's not a mind-reader.

> std.datetime isn't the only one that does this, of course.
> rndGen() in the middle of sane names like "unpredictableSeed"
> and "randomShuffle". There's more, too.

Again, it's a matter of learning the library.  Try going from Java to C#, you have to learn Console.Out instead of System.out.  Neither is intuitive or perfect, you just have to learn it.

On your grounds, I would object to your proposed names as much as I do the current ones, since I didn't guess them to begin with.

-Steve
March 07, 2012
On Tue, 06 Mar 2012 12:09:47 -0500, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> I'll never forgive std.datetime for this mistake:
>
> auto sw = StopWatch(AutoStart.yes);
> writeln(sw.peek.hnsecs);
> writeln(sw.peek.nsecs);
> writeln(sw.peek.usecs);
> writeln(sw.peek.msecs);
> writeln(sw.peek.secs);  // bzzzzz NOPE
> writeln(sw.peek.seconds);
>
> I misspell this thing every single time I use stopwatch to count seconds.

this is a no-brainer:

Duration dur(string units)(long length) @safe pure nothrow
    if(units == "weeks" ||
       units == "days" ||
       units == "hours" ||
       units == "minutes" ||
       units == "seconds" ||
       units == "secs" || // added
       units == "msecs" ||
       units == "usecs" ||
       units == "hnsecs" ||
       units == "nsecs")
{
    return Duration(convert!(units, "hnsecs")(length));
}

// etc, everywhere "seconds" is used, add "secs" as well.

I'll see if I can do a pull request.

-Steve