"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.366.1331335812.4860.digitalmars-d@puremagic.com...
> 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.
>

They eliminate the *entire* reason for it ever even being "dur" in the first place.

Of course, if this incarnation of std.datetime were a few years old, then I'd likely agree with you, but it *is* still relatively new.

On Saturday, March 10, 2012 02:21:56 Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message
> > 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.
> 
> They eliminate the *entire* reason for it ever even being "dur" in the first place.

No, they don't. You have to keep dur if you want to enable generic code. Yes, if the aliases get added, people can choose to use them instead, but that doesn't negate the value of dur. It only makes it so that it's not the only option.

> Of course, if this incarnation of std.datetime were a few years old, then I'd likely agree with you, but it *is* still relatively new.

As far as I'm concerned, changing dur to duration breaks code to no benefit. It's a pointless renaming. And regardless of how new core.time and std.datetime are, pretty much any D code doing date/time stuff right now will be using it unless it hasn't been updated any time recently, because std.date has been deprecated, and it's going to be removed in the next release.

So, as far as I'm concerned, there is _no_ way that dur is going to be change to duration. And that's exactly the sort of thing that Walter is complaining about in his thread of making breaking changes.

We might merge in the aliases, since they'll improve the situation with UFCS, but there's no way that dur is getting changed. It's a trivial change for trivial benefit, and honestly, I think that it's _worse_ for the very reasons that I chose dur in the first place. dur!"hours" is pretty much just as clear as duration!"hours", and it's shorter.

- Jonathan M Davis

On 3/10/12, Nick Sabalausky <a@a.a> wrote:
> It sounds like a great article, judging by the first paragraph, but I have to read it a couple sentences at a time.

Yikes. Here's a print version: http://drdobbs.com/article/print?articleId=184401197&siteSectionName=

On 3/9/12 11:18 PM, Nick Sabalausky wrote:
> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org>  wrote in message
> news:jjengv$agm$1@digitalmars.com...
>>
>> Insert obligatory link: http://drdobbs.com/184401197
>>
>> Very insightful article.
>>
>
> Jesus christ what the FUCK is wrong with Dr Dobbs? The article shows up
> *just fine* - *at first*, and then once all the excess junk around the edges
> finishes loading, the stupid fucking thing redirects me (WITH NO BACK
> BUTTON!) to this useless shit: http://m.drdobbs.com/
>
> What the fuck is wrong with web developers? You'd think at a
> ***PROGRAMMING*** MAGAZINE they could fucking get basic shit straight
> without scrwing up things that a NOVICE wouldn't even KNOW how to fuck up!
> Goddamn.
>
> It sounds like a great article, judging by the first paragraph, but I have
> to read it a couple sentences at a time. How the hell do "professions" botch
> things up *that* badly?

Doesn't happen on my machine. Would the printer-friendly view help?

http://drdobbs.com/article/print?articleId=184401197&siteSectionName=


Andrei

On Saturday, 10 March 2012 at 05:06:40 UTC, Andrei Alexandrescu wrote:

> Insert obligatory link: http://drdobbs.com/184401197
>
> Very insightful article.

While i tend to code that way it is not as pretty in C++ as it looks on paper when you use namespaces.

namespace ns {
  struct S {
    void b();
  }

  void b(S s);
}

auto s = ns::S;
s.b() // fine
ns::b(s) // uh..

It gets much worse when S is somewhere deep in many namespaces.
ADL helps but it is also unreliable. I think D doesn't have this issue.

On Saturday, 10 March 2012 at 09:25:28 UTC, so wrote:

> While i tend to code that way it is not as pretty in C++ as it looks on paper when you use namespaces.
>
> namespace ns {
>   struct S {
>     void b();
>   }
>
>   void b(S s);
> }
>
> auto s = ns::S;
> s.b() // fine
> ns::b(s) // uh..
>
> It gets much worse when S is somewhere deep in many namespaces.
> ADL helps but it is also unreliable. I think D doesn't have this issue.

And... at the end of the article he also mentions this.

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.399.1331365602.4860.digitalmars-d@puremagic.com...
> On Saturday, March 10, 2012 02:21:56 Nick Sabalausky wrote:
>> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message
>> > 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.
>>
>> They eliminate the *entire* reason for it ever even being "dur" in the
>> first
>> place.
>
> No, they don't. You have to keep dur if you want to enable generic code.

Sorry, I meant "...the reason for it being named 'dur' instead of 'duration'."

>...and honestly, I think that it's _worse_ for the very reasons
> that I chose dur in the first place. dur!"hours" is pretty much just as
> clear
> as duration!"hours", and it's shorter.
>

Well, I gotta say, I'm with Adam on this one: I think "duration" is much more clear, much easier to learn, and much easier to remember than "dur". Granted, I'm all for abbreviations when they're common enough, such as "curr" or "ident", but "dur" is just waaaay out there (And do we really need to invite "D: The 'Durrr' Language" heckling?).

That leaves "shorter" the only remaining reason, which becomes insignificant with the aliases, since the full "dur/duration" would be only rarely needed and the aliases are much shorter than even "dur".

On Saturday, March 10, 2012 05:31:31 Nick Sabalausky wrote:
> Well, I gotta say, I'm with Adam on this one: I think "duration" is much more clear, much easier to learn, and much easier to remember than "dur". Granted, I'm all for abbreviations when they're common enough, such as "curr" or "ident", but "dur" is just waaaay out there (And do we really need to invite "D: The 'Durrr' Language" heckling?).
> 
> That leaves "shorter" the only remaining reason, which becomes insignificant with the aliases, since the full "dur/duration" would be only rarely needed and the aliases are much shorter than even "dur".

Regardless of whether dur or duration is better, it's not worth the code breakage to change it.

- Jonathan M davis

On Saturday, 10 March 2012 at 04:56:13 UTC, Andrei Alexandrescu wrote:

>
> Yah, I'm a bit "ehm" about the sudden recommendation to use named import, too. However, I've been "ehm" about similar things in the past and came to figure that some things are just useful idioms in the forming (e.g. returning locally-defined structs).
>
> I find "import log = std.log" better and using the language more naturally than the alternative - a struct/class in conjunction with the "stuttering" convention std.log.log.

There are other solutions, such as naming the functions something less common. And there's always selective import with renaming.

Who knows, it's hard to predict what the actual effect will be.

-Steve

On 2012-03-09 22:16, Nick Sabalausky wrote:

> Note how much *nicer* it makes all the sample and unittest code.
>
>

So much better.

-- 
/Jacob Carlborg