On Thu, 08 Mar 2012 23:27:18 -0000, Nick Sabalausky <a@a.a> wrote:
>> But anyway, to me, rolling Rs seems pretentious....
>>
>
> It seems Spanish to me ;) "Get your yappy 'perro' off my leg!"

LOL :)

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Le 09/03/2012 11:58, Jonathan M Davis a écrit :
>> This is not alias. This is about accepting template parameters. The
>> actual isn't very consistent anyway (seconds, but usecs ?).
>
> It amounts to the same thing, and core.time and std.datetime are as consistent
> as they're going to get. seconds are _always_ seconds, and _no_ units greater
> than seconds are ever abbreviated. Only the sub-second units are abbreviated.
> And they're abbreviated only because they would have been way too long
> otherwise. And making seconds secs would create even _more_ inconsistencies.
> Just read the discusion in the pull request:
>
> https://github.com/D-Programming-Language/druntime/pull/173
>
> - Jonathan M Davis

Yes, this is consistent in this regards. What isn't consistent is to choose to not abbreviate seconds, hours, minutes, but to abbreviate nsecs, usecs.

Considering the existing codebase, I think the best option now is to allow both. In an ideal worlds, I would argue that we go for all abbreviation or none.

I did read, the topic. Interesting, but I think walter isn't consistent with its own argumentation on point 6. Consider that in french, « dur » means « hard ». Even associated with keyword like dlang, this is 100% ungooglable. He is also plain wrong on point 5. No progress is made for experienced D programmers (arghuably, it is a step backward for such people), but for newcomers it is. At some point, we will have to consider newcomers as an important subject.

I do agree with most other points, this is not good to have 2 names for the same thing. However, the actual names are confusing, it seems that this thread make it pretty much clear. A lot of people have trouble with dur and seconds. Now, instead of changing everything that exists, lets make secs available. This isn't perfect, but it is the consequence of the inconsistency of naming convention that occurs (between sub seconds units and other units) in a first place, not the ideal case.

PS: just to be clear, I do agree with most of what you said here : https://github.com/D-Programming-Language/druntime/pull/173

On 3/9/12 6:17 AM, Jonathan M Davis wrote:
> On Friday, March 09, 2012 01:07:57 Jonathan M Davis wrote:
>> On Friday, March 09, 2012 09:55:50 deadalnix wrote:
>>> Le 09/03/2012 05:42, H. S. Teoh a écrit :
>>>> On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote:
>>>>> On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote:
>>>>>> IMO, making all abbreviations in Phobos consistent would be a big
>>>>>> step forward.
>>>>>
>>>>> You know, people keep saying that the abbreviations are inconsistent,
>>>>> but I don't buy that. _What_ abbreviations are inconsistent?
>>>>
>>>> [...]
>>>>
>>>> My comment was referring specifically to the pull request that adds
>>>> "secs" as an alternative for "seconds". From what Walter said, he seems
>>>> to be against any renaming changes, so any existing inconsistencies that
>>>> we might find seems likely to be rejected as well.
>>>
>>> Why it isn't possible to support both ? And miliseconds as well a usecs
>>> ? This make sense, as long as they are both common.
>>
>> Because it creates needless aliases. Now you have to remember _both_ of
>> them, because they're both going to be used in code. And people reading
>> code will wonder what the difference is. It just adds more confusion to the
>> library and reduces its cohesiveness and consistency. It works far better
>> to just have the one symbol. Isn't that one of the major complaints about
>> PHP? That it has a ton of different ways to do the same thing?
>>
>> Walter and Andrei are very much against having aliases in the library just
>> to create different names for the same stuff. And adding more options for
>> the time units argument to the templates that use them is basically the
>> same thing. So, we're not going to add such aliases. It's not like it's all
>> that hard to learn the library, and none of the names are horribly wrong.
>> They just don't happen to be the names that you prefer. You have to learn
>> the names of the symbols of _any_ library that you use. This is no
>> different.
>
> If you want to read Walter's arguments on the matter as well as more detailed
> discussion on this particular case, then just read the comments in the now
> closed pull requested for adding "secs":
>
> https://github.com/D-Programming-Language/druntime/pull/173
>
> - Jonathan M Davis

Sample Ruby session:

> irb
ruby-1.8.7-p352 :001 > [1, 2, 3].count
 => 3
ruby-1.8.7-p352 :002 > [1, 2, 3].length
 => 3
ruby-1.8.7-p352 :003 > [1, 2, 3].size
 => 3

I never saw *anyone* complaining about this. When you write, you choose whatever is convenient to you (whatever comes to your mind first). When you read it, it's understandable. Nobody wonders "why didn't he wrote 'length' instead of 'size'", because the meaning is clear.

On 03/08/2012 10:07 PM, H. S. Teoh wrote:
> On Thu, Mar 08, 2012 at 05:45:47PM -0300, Ary Manzana wrote:
>> On 3/8/12 7:27 AM, Timon Gehr wrote:
>>> On 03/08/2012 03:14 AM, Ary Manzana wrote:
>>>> 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]}]
>>>>
>>>> Or I could have written:
>>>>
>>>> Hash[
>>>> Site.find(
>>>> results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact
>>>> ).map{|x| [x.id, x]}
>>>> ]
>>>>
>>>> No abbreviation at all,
>>>
>>> uniq.
> [...]
>
> And ids.
>
>
> T
>

Is that in some standard library interface?

On Wed, 07 Mar 2012 17:11:43 -0500, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Wed, 07 Mar 2012 10:25:32 -0500, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>
>> On Wed, 07 Mar 2012 08:47:48 -0500, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>>
>>> I'll see if I can do a pull request.
>>
>> Almost done, need to test:
>>
>> https://github.com/schveiguy/druntime/commit/cf9d1ba4f5498c447d91497cb5edbd735d2b4c7e
>>
>> Actually cleans up a lot of the template constraints too...
>
> https://github.com/D-Programming-Language/druntime/pull/173
>
> https://github.com/D-Programming-Language/phobos/pull/483

These have been rejected, so I guess you're stuck with seconds instead of secs :(

-Steve

 YOn 03/09/2012 09:12 AM, deadalnix wrote:
> Le 07/03/2012 11:08, Timon Gehr a écrit :
>> On 03/06/2012 10:30 PM, deadalnix wrote:
>>>
>>> auto helps too.
>>
>> This remark was explicitly about _Java_ code style.
>
> 1/ We are not in the java's newsgroup.
> 2/ In java, the tooling is that awesome that you don't need to type most
> of it anyway.

1/ We are not in the tooling's newsgroup.
2/ I am aware of that.

On Thu, Mar 08, 2012 at 11:01:21PM -0800, Jonathan M Davis wrote:
> On Friday, March 09, 2012 01:45:13 Nick Sabalausky wrote:
[...]
> > That's one great thing about Ohio: A few years back we had a state law passed here (by public vote! I had been convinced it wouldn't pass) prohibiting smoking in workplaces and public buildings/businesses. That includes, of course, restaurants. No more smoking sections! I feel so spoiled now when I travel to a state that still has public indoor smoking.  It's like stepping back into the stone age.
> 
> I'm from California, where it's been illegal to smoke in restaurants for 15+ years now, and it always shocks me to see a smoking section in restaurants in other states. It's not something that I even think about.
[...]

You think it's bad to have a smoking section in restaurants? Back in the old days (I'm pretty sure it isn't the case anymore -- at least I sure hope not!), Japan Airlines used to have a smoking section in the cabin. I was on a *transatlantic* flight like that once. You cannot imagine my relief after the flight was finally over.


T

-- 
Give me some fresh salted fish, please.

On 2012-03-09 15:39, Timon Gehr wrote:
> On 03/08/2012 10:07 PM, H. S. Teoh wrote:
>> On Thu, Mar 08, 2012 at 05:45:47PM -0300, Ary Manzana wrote:
>>> On 3/8/12 7:27 AM, Timon Gehr wrote:
>>>> On 03/08/2012 03:14 AM, Ary Manzana wrote:
>>>>> 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]}]
>>>>>
>>>>> Or I could have written:
>>>>>
>>>>> Hash[
>>>>> Site.find(
>>>>> results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact
>>>>> ).map{|x| [x.id, x]}
>>>>> ]
>>>>>
>>>>> No abbreviation at all,
>>>>
>>>> uniq.
>> [...]
>>
>> And ids.
>>
>>
>> T
>>
>
> Is that in some standard library interface?

Site.find is part of ActiveRecord (part of Rails), the rest is part of the core (standard) library.

-- 
/Jacob Carlborg

On Fri, Mar 9, 2012 at 1:46 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Friday, March 09, 2012 09:33:20 deadalnix wrote:
> > Le 07/03/2012 02:00, F i L a écrit :
> > > I personally find it much easier to remember and use longer, more sentance-like method names. However, Jonathan and others obviously feel more comfortable writing with a high level of abbreviation, which they justify rather well. Still, if D's goal is to gain popularity, I think it should take notices of other rising languages like C#.
> > >
> > > The problem with making any change to Phobos is backwards
> compatibility.
> >
> > We just need a politic for the change. IE: make the old name a warning, then deprecated, then remove it. Spread the process to a year or so.
>
> We're not changing symbol names without a good reason. Yes, there's a deprecation process that allows us to change them if we need to, but it's still disruptive.
>
> - Jonathan M Davis
>

The "secs" and "seconds" inconsistency is something I've seen people in IRC
hit and complain about on several occasions.  The dur!"seconds"(1) syntax
I've seen complained about or confusion over on both IRC and on reddit by
active and potential users.  While I don't feel particularly strong about
these issues I feel I should point out that actual users are hitting them
and the issues bug them enough that they feel the need to
complain publicly.  Changes must be made with care but the former issue on
inconsistency, I would argue, is a bigger issue than, say, the current
symbol deprecation/replace of toISOExtendedString (though I don't know the
history of the decision to make the change).

There shouldn't be two ways of expressing the exact same thing so the "secs"/"seconds" should be a substitute and deprecate process rather than just a simple alias if it were made. It looks like it's been rejected already, though, which is unfortunate.  phobos is still a young library (or at least parts of it, like datetime, are) and so these types of wart removal could be made with limited disruption to current users.

The dur aliases would be welcome because they increase readability, intuitive design, and brevity.  I know I just said their shouldn't be two ways of doing the same thing but I don't feel this is the case here.  It's a shortcut to doing exactly one thing and, as I said before, I wouldn't want to lose the option of genericity. I just want to make specification of it optional since I would use seconds(5) a great deal more often than dur!base(5) (though I would use the latter fairly frequently in my line of work).

Anyway, I just felt I'd share my opinion and what I've witnessed of other users so it's at least it's heard and taken into consideration. The decision is ultimately yours and Walter's.

Regards,
Brad Anderson