On Wednesday, March 07, 2012 22:55:51 Stewart Gordon wrote:
> The mention of this one reminds me of another issue: capitalisation consistency.  It would be nice to standardise whether acronyms/initialisms occurring within names have just the first letter or all letters capitalised.  I'm thinking best is to treat them as words and therefore capitalise just the first letter.  Though I've been known to do otherwise in the past.

I'm completely in favor of treating acronyms as being all captalized if the first letter is capitilized and all lowercase if the first letter is lowercase. It's actually a bit of a pet peeve of mine when people do stuff like Ascii instead of ASCII. And most of Phobos goes with fully capitilizing rather than just capitilizing the first letter. It's not completely consistent though.

> But it's confusing enough that there are still many functions in Phobos whose names are all lowercase when they should be camelCase.

That's _mostly_ been fixed. The main remaining culprits that I'm aware of are the std.string functions which take patterns. There was some discussion of replacing them with functions which take regexes. If we do that, then they'll be replaced with properly camelcased names. But _most_ of the function names in Phobos have been fixed to be properly camelcased.

- Jonathan M Davis

On 8 March 2012 15:56, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Thursday, March 08, 2012 01:22:42 Stewart Gordon wrote:
>> On 07/03/2012 08:10, Jacob Carlborg wrote:
>> <snip>
>>
>> > Yeah, Clock.now() would be good and Data.today() as well.
>>
>> My utility library has, for consistency, DateValue.now, TimeValue.now and DateTime.now.
>
> I specically avoided giving a way to get the time with any type other than SysTime (and TickDuration for using a monotonic clock), because I believe that it leads to incorrect behavior. Any time that you're dealing with the system clock, you should be dealing with SysTime. Date, TimeOfDay, and DateTime are for when you need the date and/or time but don't care about what absolute time it's associated with in the real world. Treating DateTime as corresponding to a specific point in time is just going to cause problems, because it has no time zone. It could correspond to over 24 different times. By restricting getting the time to SysTime, it encourages the writing of correct code.
>
> - Jonathan M Davis

It tends to be better to go for proper timezoned code from the outset, a workmate just had to add timezone support to the entire app recently, took him about 2 weeks.

--
James Miller

On Thursday, March 08, 2012 16:18:39 James Miller wrote:
> On 8 March 2012 15:56, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > On Thursday, March 08, 2012 01:22:42 Stewart Gordon wrote:
> >> On 07/03/2012 08:10, Jacob Carlborg wrote:
> >> <snip>
> >> 
> >> > Yeah, Clock.now() would be good and Data.today() as well.
> >> 
> >> My utility library has, for consistency, DateValue.now, TimeValue.now and DateTime.now.
> > 
> > I specically avoided giving a way to get the time with any type other than SysTime (and TickDuration for using a monotonic clock), because I believe that it leads to incorrect behavior. Any time that you're dealing with the system clock, you should be dealing with SysTime. Date, TimeOfDay, and DateTime are for when you need the date and/or time but don't care about what absolute time it's associated with in the real world. Treating DateTime as corresponding to a specific point in time is just going to cause problems, because it has no time zone. It could correspond to over 24 different times. By restricting getting the time to SysTime, it encourages the writing of correct code.
> > 
> > - Jonathan M Davis
> 
> It tends to be better to go for proper timezoned code from the outset, a workmate just had to add timezone support to the entire app recently, took him about 2 weeks.

Definitely. The whole reason that I wrote std.datetime and that SysTime works the way that it does is because I've had to deal with enough time-related bugs at work that I was sick of it, and I wanted to make sure that D had a solution that did it right. And by maintaining its time in UTC internally and just adjusting the time to a particular time zone when required for output (e.g. getting the year of the SysTime or converting it to a string), a whole host of conversion errors are avoided (DST is _the_ largest mistake with regards to time in the history of computing IMHO).

Unfortunately, errors are still possible (e.g. sometimes you have to create a SysTime from a DateTime, and that can't be done without risking DST-related errors), but I believe that SysTime manages to reduce them about as much as is possible. So, in general, if you use SysTime, time should just be handled correctly without you having to worry about all of the details - like the time zone. But it also gives you the power to do more if you _do_ care about the details (e.g. selecting a specific time zone).

- Jonathan M Davis

On 3/8/2012 4:27 AM, Jonathan M Davis wrote:
> On Wednesday, March 07, 2012 08:47:48 Steven Schveighoffer wrote:
>> 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.
>
> I've avoided that primarily because it results in inconsistent code. It's
> pretty much equivalent to adding extraneous aliases, though it's not as bad,
> since it's not a general symbol. But if it's a sufficient usability improvement,
> then maybe it's a good idea.
>

In this case, I think it very much is. I saw your explanation earlier that everything sub-second is abbreviated, but to me (and several others, obviously) that's just unintuitive. I see "msecs", "usecs", and so on and I naturally think "secs" rather than "seconds", most likely because it's a part of each abbreviation. Steve's solution is the right one, I think.

On 3/7/2012 8:20 PM, Kapps wrote:
> On Wednesday, 7 March 2012 at 19:12:25 UTC, H. S. Teoh wrote:
>> Supporting stuff like 5.hours will introduce additional complications to
>> D's lexical structure, though. The lexer will have to understand it as
>> (int:5)(.)(ident:hours) rather than (float:5.)(ident:hours). And then if
>> you actually *wanted* a float, you'd have another ambiguity: 5..hours
>> could mean (float:5.)(.)(ident:hours) or (int:5)(..)(hours). And
>> 5.0.hours just looks... weird.
>>
>>
>> T
>
> Actually, Kenji's pull request for UFCS already takes care of this.
> Things like 5. aren't allowed, nor is 5.f; a number has to follow the
> decimal. So 5.f would invoke UFCS function f with the integer 5. I
> believe this change is already merged, though the rest of the UFCS pull
> request isn't unfortunately.

I can definitely confirm that porting C/C++ floating point literals to D is a huge pain in the ass because of this change, so its definitely in to the degree it breaks my math and physics libs heavily :)

"Ary Manzana" <ary@esperanto.org.ar> wrote in message news:jj94mb$1i7v$1@digitalmars.com...
>
> Here's something I wrote today:
>
> parent_ids = results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact Hash[Site.find(parent_ids).map{|x| [x.id, x]}]
>

When you format it like that (that is to say, when you *don't* format it), yea, it's unreadable. Which is why I do such things like this:

parent_ids =
    results
    .map{|x| x['_source']['parent_ids']}
    .flatten.uniq
    .compactHash[
        Site.find(parent_ids).map{|x| [x.id, x]}
    ]

On Thursday, March 08, 2012 00:52:57 Nick Sabalausky wrote:
> "Ary Manzana" <ary@esperanto.org.ar> wrote in message news:jj94mb$1i7v$1@digitalmars.com...
> 
> > Here's something I wrote today:
> > 
> > parent_ids = results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact Hash[Site.find(parent_ids).map{|x| [x.id, x]}]
> 
> When you format it like that (that is to say, when you *don't* format it), yea, it's unreadable. Which is why I do such things like this:
> 
> parent_ids =
>     results
>     .map{|x| x['_source']['parent_ids']}
>     .flatten.uniq
>     .compactHash[
>         Site.find(parent_ids).map{|x| [x.id, x]}
>     ]

I actually tend to find code like that hard to read, because all of the operations are inside out in comparison to normal. But since the only difference between his example and yours is the formatting, I agree yours is easier to read. Still, I'd much prefer if such code didn't use UFCS, since I find it much harder to read that way. It's just so backwards.

- Jonathan M Davis

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.214.1331187413.4860.digitalmars-d@puremagic.com...
> On Thursday, March 08, 2012 00:52:57 Nick Sabalausky wrote:
>> "Ary Manzana" <ary@esperanto.org.ar> wrote in message news:jj94mb$1i7v$1@digitalmars.com...
>>
>> > Here's something I wrote today:
>> >
>> > parent_ids = results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact Hash[Site.find(parent_ids).map{|x| [x.id, x]}]
>>
>> When you format it like that (that is to say, when you *don't* format
>> it),
>> yea, it's unreadable. Which is why I do such things like this:
>>
>> parent_ids =
>>     results
>>     .map{|x| x['_source']['parent_ids']}
>>     .flatten.uniq
>>     .compactHash[
>>         Site.find(parent_ids).map{|x| [x.id, x]}
>>     ]
>
> I actually tend to find code like that hard to read, because all of the
> operations are inside out in comparison to normal. But since the only
> difference between his example and yours is the formatting, I agree yours
> is
> easier to read. Still, I'd much prefer if such code didn't use UFCS, since
> I
> find it much harder to read that way. It's just so backwards.
>

Aside from the problems of excess paren nesting, I tend to think this is backwards:

foo(bar(baz(x+2)))

...because the order it's read/written is the complete opposite of the order of exectution. First "x+2" is evaluated, then "baz", then "bar", then "foo". Ie, it's executed right-to-left even though you read/write it left-to-right. Completely backwards. Contrast that with:

(x+2).baz().bar().foo()

...which we may be less accustomed to (unless you think of it like bash piping), but in addition to the decrease in nesting, it's written and read in the *same* order as exection: left to right. This also means that it's no longer the complete reverse of statements which are (sensibly) left-to-right:

y = x+2; baz(); bar(); foo();

If I were writing code in Arabic, I would probably like "foo(bar(baz(x+2)))". (I would also wonder "What a minute, when did I learn Arabic? How did I manage to learn a langauge without even knowing? This is really weird! But fun. Wheee!!")

On 2012-03-07 19:40, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:jj755f$r7u$1@digitalmars.com...
>> 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.
>>
>
> I dunno, on the second one, I think I'd prefer "Date.today()" ;)
>
> (Nyuk nyuk nyuk)
>
>

Hehe, missed that :)

-- 
/Jacob Carlborg

On 2012-03-07 19:50, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:jj74p4$n9r$3@digitalmars.com...
>> 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.
>>
>
> I like that so many people agree with this. But I do want to point out
> again, just in case anyone missed it, that I'm hoping it would *actually*
> be:
>
> alias duration!"years" years;
> alias duration!"months" months;
> etc...

That's what I was hoping for as well.

> Since the aliases themselves mitigate the need for "duration" itself to be
> shortened.
>
> Course, I can still live with just 'alias dur!"years" years;..etc...'. The
> *main* thing is that we can just do "hours(5)"...(or heck, once UFCS finally
> gets fixed: "5.hours")

That would be so nice. Actually UFCS seems to have been merged now:

https://github.com/D-Programming-Language/dmd/commit/b7742f7a733ff73d364c6ed54af70d875d7e911b

-- 
/Jacob Carlborg