"Ary Manzana" <ary@esperanto.org.ar> wrote in message news:jjdqe4$1oeb$1@digitalmars.com...
>
> Indeed, count can be used to count elements:
>
> ruby-1.8.7-p352 :002 > [1, 2, 3, 3, 3].count 3
>  => 3
> ruby-1.8.7-p352 :004 > [1, 2, 3, 3, 3].count &:odd?
>  => 4
> ruby-1.8.7-p352 :005 > [1, 2, 3, 3, 3].count { |x| x <= 2 }
>  => 2
>

Interesting idea.

>>
>> IMAO, this sort of "write your mind and somehow it just works" thing only encourages lazy programming (guessing what something does without knowing for sure, and copy-n-pasting code without understanding it, which leads to bit rot and hideous patchwork code that houses all sorts of subtle bugs and corner-case failures).
>
> We also write lots of tests in Ruby. :-P

Writing plenty of tests is good no matter what, but it's an inferior substitute for proper compile-time checks. Not that that's applicable to this "count vs length vs size" subdiscussion, of course. Just a general comment on the dynamic world's fairly common "lots of tests" excuse.

On 3/9/12 6:21 PM, Nick Sabalausky wrote:
> "Ary Manzana"<ary@esperanto.org.ar>  wrote in message
> news:jjdqe4$1oeb$1@digitalmars.com...
>>
>> Indeed, count can be used to count elements:
>>
>> ruby-1.8.7-p352 :002>  [1, 2, 3, 3, 3].count 3
>>   =>  3
>> ruby-1.8.7-p352 :004>  [1, 2, 3, 3, 3].count&:odd?
>>   =>  4
>> ruby-1.8.7-p352 :005>  [1, 2, 3, 3, 3].count { |x| x<= 2 }
>>   =>  2
>>
>
> Interesting idea.
>
>>>
>>> IMAO, this sort of "write your mind and somehow it just works" thing
>>> only encourages lazy programming (guessing what something does without
>>> knowing for sure, and copy-n-pasting code without understanding it,
>>> which leads to bit rot and hideous patchwork code that houses all sorts
>>> of subtle bugs and corner-case failures).
>>
>> We also write lots of tests in Ruby. :-P
>
> Writing plenty of tests is good no matter what, but it's an inferior
> substitute for proper compile-time checks. Not that that's applicable to
> this "count vs length vs size" subdiscussion, of course. Just a general
> comment on the dynamic world's fairly common "lots of tests" excuse.

True. I'd like to find (or do) a language that combines both of two worlds.

I started one, but I don't have much time to continue it and also I'm stuck with design/implementation decisions. :-P

https://github.com/asterite/crystal

(not everything in the bullet list is implemented, those are just wishes, but everything in "samples" compiles and runs)

And other people had similar ideas:

http://whitequark.org/blog/2011/12/21/statically-compiled-ruby/

On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky <a@a.a> wrote:

> "Nick Sabalausky" <a@a.a> wrote in message
> news:jj6gjm$2m6a$1@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.

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

-Steve

On Friday, March 09, 2012 16:36:27 Steven Schveighoffer wrote:
> On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky <a@a.a> wrote:
> > "Nick Sabalausky" <a@a.a> wrote in message news:jj6gjm$2m6a$1@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.
> 
> I can't say I agree with this, as it pollutes the global namespace with several common terms that could be used for fields.

Yeah. My general reaction is that this is a _bad_ idea. It creates aliases and uses names for free functions which are commonly used. We'll see if Walter says anything about this one, but my first reaction is to reject it. I'll wait for comments on it though.

- Jonathan M Davis

On Friday, 9 March 2012 at 21:36:28 UTC, Steven Schveighoffer wrote:
> I can't say I agree with this, as it pollutes the global namespace with several common terms that could be used for fields.

There's no such thing as a global namespace in D, and
field names wouldn't be affected even if there was one.

int minutes(int i) {
	return i;
}

struct A {
	int minutes; // not a problem
        void foo() {
             minutes = .minutes(1); // works
	}
}

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.waxaa1s1eav7ka@localhost.localdomain...
> On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky <a@a.a> wrote:
>
>> "Nick Sabalausky" <a@a.a> wrote in message news:jj6gjm$2m6a$1@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

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.357.1331329638.4860.digitalmars-d@puremagic.com...
> On Friday, March 09, 2012 16:36:27 Steven Schveighoffer wrote:
>> On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky <a@a.a> wrote:
>> > "Nick Sabalausky" <a@a.a> wrote in message news:jj6gjm$2m6a$1@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.
>>
>> I can't say I agree with this, as it pollutes the global namespace with several common terms that could be used for fields.
>
> Yeah. My general reaction is that this is a _bad_ idea. It creates aliases
> and
> uses names for free functions which are commonly used. We'll see if Walter
> says
> anything about this one, but my first reaction is to reject it. I'll wait
> for
> comments on it though.
>

If that's the case, then this alias-phobia will have *truly* gotten completely out of hand.

"Nick Sabalausky" <a@a.a> wrote in message news:jjdu0j$209o$1@digitalmars.com...
>> 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
>

Plus, having to [**occasionally**] change a "minutes" to "numMinutes" (or something, frankly, much more descriptive) is a hell of a lot better than having to use 'dur!"minutes"(5)' instead of 'minutes(5)'.

On Fri, 09 Mar 2012 16:47:01 -0500, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Friday, March 09, 2012 16:36:27 Steven Schveighoffer wrote:
>> On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky <a@a.a> wrote:
>> > "Nick Sabalausky" <a@a.a> wrote in message
>> > news:jj6gjm$2m6a$1@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.
>>
>> I can't say I agree with this, as it pollutes the global namespace with
>> several common terms that could be used for fields.
>
> Yeah. My general reaction is that this is a _bad_ idea. It creates aliases and
> uses names for free functions which are commonly used. We'll see if Walter says
> anything about this one, but my first reaction is to reject it. I'll wait for
> comments on it though.

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.

-Steve

On Fri, 09 Mar 2012 17:38:08 -0500, Nick Sabalausky <a@a.a> wrote:

> "Nick Sabalausky" <a@a.a> wrote in message
> news:jjdu0j$209o$1@digitalmars.com...
>>> 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
>>
>
> Plus, having to [**occasionally**] change a "minutes" to "numMinutes" (or
> something, frankly, much more descriptive) is a hell of a lot better than
> having to use 'dur!"minutes"(5)' instead of 'minutes(5)'.

I find both equally descriptive and neither one too offensive.  All things being equal, dur wins because it consumes only one top-level symbol, and is already there.

This is all my opinion of course, and we've already seen how much affect that has ;)

-Steve