On Fri, 09 Mar 2012 16:50:22 -0500, Adam D. Ruppe <destructionator@gmail.com> wrote:

> 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.

Of course there isn't.  What I meant was the module level namespace.  Any file you import by default goes into your current module namespace.  In effect it's the global namespace *for your module*.

But if I have to spell that out every time, it's going to be a lot of typing.  It's generally understood that the "global namespace" is the effective global namespace during your module.  Yes, there are ways to rename imports, I find it poor design to *require* renaming imports.

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

Again, I find this just as descriptive and not terrible to type:

struct A {
  Duration minutes;
  void foo() {
      minutes = dur!"minutes"(1);
  }
}

-Steve

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.

- Jonathan M Davis

On Friday, 9 March 2012 at 22:54:37 UTC, Steven Schveighoffer wrote:
> Again, I find this just as descriptive and not terrible to type:

Yeah, that's fine by me (though duration is still better
than dur :-D )

I'm just the name conflict isn't a big deal either
since writing ".minutes" in some places to disambiguate
the scope works in most cases too.

On 3/9/12 5:54 AM, Ary Manzana wrote:
> 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.

I don't think this sits well in the D culture.

Andrei

On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis <jmdavisProg@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.
>
>
What remains on UFCS? I've heard someone (Nick?) say he'd like it to match
static member functions too.  I haven't tested but it seems like
5.seconds() should work ever since Kenji's pull request was merged a couple
of days ago (thanks Kenji and Walter, I'm really looking forward to that
change).

Regards,
Brad Anderson


> 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.
>
> - Jonathan M Davis
>

On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis <jmdavisProg@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.

Regards,
Brad Anderson

- Jonathan M Davis
>

On Friday, March 09, 2012 16:08:34 Brad Anderson wrote:
> On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis <jmdavisProg@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.
> 
> What remains on UFCS? I've heard someone (Nick?) say he'd like it to match
> static member functions too. I haven't tested but it seems like
> 5.seconds() should work ever since Kenji's pull request was merged a couple
> of days ago (thanks Kenji and Walter, I'm really looking forward to that
> change).

I don't know what the current state of UFCS is. I know that Kenji has been working on it and that at least some portion of it has been checked in, but what exactly it enables at this point, I don't know.

- Jonathan M Davis

On Friday, March 09, 2012 16:16:56 Brad Anderson wrote:
> On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis <jmdavisProg@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.

- Jonathan M Davis

On Fri, Mar 9, 2012 at 4:24 PM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Friday, March 09, 2012 16:08:34 Brad Anderson wrote:
> > On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis <jmdavisProg@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.
> >
> > What remains on UFCS? I've heard someone (Nick?) say he'd like it to
> match
> > static member functions too. I haven't tested but it seems like 5.seconds() should work ever since Kenji's pull request was merged a
> couple
> > of days ago (thanks Kenji and Walter, I'm really looking forward to that
> > change).
>
> I don't know what the current state of UFCS is. I know that Kenji has been working on it and that at least some portion of it has been checked in, but what exactly it enables at this point, I don't know.
>
> - Jonathan M Davis
>

Here are the unittests he added if you are curious about what currently
works in dmd HEAD:
https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/ufcs.d

The issue "[tdpl] Implement uniform function call syntax" < http://d.puremagic.com/issues/show_bug.cgi?id=3382> is marked as RESOLVED FIXED so, as far as I know, UFCS is done (ignoring the inevitable bugs that will eventually be uncovered).

Regards,
Brad Anderson

On Fri, 09 Mar 2012 18:16:56 -0500, Brad Anderson <eco@gnuk.net> wrote:

> On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis <jmdavisProg@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++).

I want to stress again the difference between C++'s namespaces, and D's module import mechanism.  In C++, you *deliberately* pull a namespace into your scope (and usually only in the implementation file, which doesn't affect any other implementation files), whereas in D, a standard "import std.datetime" *automatically* pulls its namespace into your scope, and any public imports it has made.

I've used boost's datetime.  I didn't really like the whole "different types for each unit" mechanism, but I used it with success, and was glad I didn't have to re-invent it :)  But then again, I used it as the original date/time lib for my project.

-Steve