www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - (git HEAD) std.datetime spewing deprecation messages

reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
https://issues.dlang.org/show_bug.cgi?id=12846

Since when is x.hours, x.minutes, etc., deprecated? Well, in any case,
looks like std.datetime needs to be fixed.


--T
Jun 03 2014
next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 03 Jun 2014 18:35:31 +0100
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Tue, 2014-06-03 at 10:00 -0700, Jonathan M Davis via Digitalmars-d
 wrote:
 On Tue, 3 Jun 2014 07:21:12 -0700
 "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:

 https://issues.dlang.org/show_bug.cgi?id=12846

 Since when is x.hours, x.minutes, etc., deprecated?

As of Sunday. The problem is that they seem to be very prone for misuse.

I think x.hours and x.minutes are fine per se. I would suggest deeper investigation of the perceived problems rather than just deprecate then remove.
 Not only do they not match what TickDuration uses those same names
 for (it uses them for the equivelent of total!"hours"(), etc.
 rather than get!"hours"(), etc.), which has come up a number of
 times before, but what I've found at work (where we have a C++ port
 of Duration) is that pretty much everyone keeps using get when they
 meant total, consistently causing subtle bugs. So, I've come to the
 conclusion that the current design is just too bug-prone, and by
 deprecating the individual getters and renaming get to getOnly, I
 hope that that will seriously reduce the risk of misuse.

This all sounds like implementation detail rather than API usage. I admit not having used this stuff in D, but the same basic system exists in Groovy and it works just fine.

The problem is that folks assume that they know what the functions do, and they consistently seem to assume incorrectly. I would have thought that having the documentation be clear would have been sufficient, but it hasn't been, because too many people don't read it, or they read it and then don't remember it correctly later. And since getting the individual units of a Duration rather than the total is likely to be a relatively rare operation, I think that having the individual getters for extracting the individual units is just begging for trouble. I fully expect that the vast majority of users who will end up with deprecation warnings due to these changes will have found a bug in their code. - Jonathan M Davis
Jun 03 2014
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 5 Jun 2014 14:35:16 +0000 (UTC)
Byron Heads via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Thu, 05 Jun 2014 07:18:59 -0700, H. S. Teoh via Digitalmars-d
 wrote:

 On Thu, Jun 05, 2014 at 01:23:47AM -0700, Jonathan M Davis via
 Digitalmars-d wrote:
 {
     auto d = dur!"days"(12) + dur!"minutes"(7) +
 dur!"usecs"(501223); long days;
     int seconds;
     short msecs;
     d.split!("days", "seconds", "msecs")(&days, &seconds, &msecs);
     assert(days == 12);
     assert(seconds == 7 * 60);
     assert(msecs == 501);

[...] Very nice! I like this. It looks very D-ish, and very idiomatic.

if only we could avoid the quotes, would a enum array work? d.split![days, second, msecs](...)

It's a common idiom in core.time and std.datetime to use strings to represent units when you need to give the units as template arguments. If it hade't been strings, it would have been an enum (otherwise, they would risk conflicting with local variables and whatnot), in which case it would have been even more verbose - e.g. Units.days, Unit.seconds, Unit.msecs (and IIRC, I originally had something like that until Anrei suggested that I use strings in the original review for std.datetime). Also, days, seconds, and msecs are free functions in core.time which forward to dur!"days", dur!"seconds", and dur!"msecs", so trying to use them on their own would try and use those free functions, which obviously isn't what we want at all. I can see why you might want to remove the quotes, but they really aren't that bad, and using strings for this purpose has turned out to be extremely useful and flexible. - Jonathn M Davis
Jun 05 2014
parent Byron Heads <byron.heads gmail.com> writes:
On Thu, 05 Jun 2014 21:00:39 +0200, Jonathan M Davis via Digitalmars-d
wrote:

 It's a common idiom in core.time and std.datetime to use strings to
 represent units when you need to give the units as template arguments.
 If it hade't been strings, it would have been an enum (otherwise, they
 would risk conflicting with local variables and whatnot), in which case
 it would have been even more verbose - e.g. Units.days, Unit.seconds,
 Unit.msecs (and IIRC, I originally had something like that until Anrei
 suggested that I use strings in the original review for std.datetime).
 Also, days, seconds, and msecs are free functions in core.time which
 forward to dur!"days", dur!"seconds", and dur!"msecs", so trying to use
 them on their own would try and use those free functions, which
 obviously isn't what we want at all. I can see why you might want to
 remove the quotes, but they really aren't that bad, and using strings
 for this purpose has turned out to be extremely useful and flexible.
 
 - Jonathn M Davis

Yeah its more of a pipe dream, kinda of how we have moved away from passing strings and use the short hand versions of lambdas. A CTFE helper might make it look better, saw this somewhere on the form. d.splitHelper!q{days, second, msecs}(...) the function name is not import here just the idea. There is a stdx project on code.dlang, might be a good place for little helpers like this.
Jun 06 2014
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 05 Jun 2014 18:18:33 -0400
Steven Schveighoffer via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 On Thu, 05 Jun 2014 18:06:01 -0400, monarch_dodra
 <monarchdodra gmail.com> wrote:

 On Thursday, 5 June 2014 at 08:49:18 UTC, Jonathan M Davis via
 Digitalmars-d
     long days;
     int seconds;
     short msecs;
     d.split!("days", "seconds", "msecs")(&days, &seconds, &msecs);

Please don't use pass-by-pointer in D APIs. It makes it a real *nightmare* to ever use the code in a safe context.

This is similar to getopt and readf. I think it's a good way to show that a reference is being passed.

And like with them, it's impossible to use ref for this, because you can't use ref with variadic template arguments. So, there isn't even any debate as to whether ref or pointers would be nicer. Since it's _impossible_ to use ref for this, there's no choice. Anyone who doesn't want to use pointers can use the overload that returns a struct rather than taking function arguments. If there were a way to use ref with variadic arguments, then we could discuss which is better, but since pointers are the only option, there's no point in discussing it. - Jonathan M Davis
Jun 05 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 6 June 2014 at 00:34:19 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
 And like with them, it's impossible to use ref for this, 
 because you can't use
 ref with variadic template arguments.

Wait what? void foo(T...)(ref T args) { args[0] = 42; } void main() { int x; foo(x); assert(x == 42); }
Jun 06 2014
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 06 Jun 2014 08:14:13 +0000
Dicebot via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Friday, 6 June 2014 at 00:34:19 UTC, Jonathan M Davis via
 Digitalmars-d wrote:
 And like with them, it's impossible to use ref for this,
 because you can't use
 ref with variadic template arguments.

Wait what? void foo(T...)(ref T args) { args[0] = 42; } void main() { int x; foo(x); assert(x == 42); }

Well, that's new then. You didn't used to be able to do that. I clearly missed that change. Thanks for the correction. I'd still use pointers in this case though, since it's clearer and consistent with existing code like getopt. - Jonathan M Davis
Jun 06 2014
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 6 June 2014 at 09:35:56 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
 On Fri, 06 Jun 2014 08:14:13 +0000
 Dicebot via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Friday, 6 June 2014 at 00:34:19 UTC, Jonathan M Davis via
 Digitalmars-d wrote:
 And like with them, it's impossible to use ref for this,
 because you can't use
 ref with variadic template arguments.

Wait what? void foo(T...)(ref T args) { args[0] = 42; } void main() { int x; foo(x); assert(x == 42); }

Well, that's new then. You didn't used to be able to do that. I clearly missed that change. Thanks for the correction. I'd still use pointers in this case though, since it's clearer and consistent with existing code like getopt. - Jonathan M Davis

And strongly system.
Jun 06 2014
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 6 June 2014 at 10:35:58 UTC, monarch_dodra wrote:
 On Friday, 6 June 2014 at 09:35:56 UTC, Jonathan M Davis via 
 Digitalmars-d wrote:
 On Fri, 06 Jun 2014 08:14:13 +0000
 Dicebot via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Friday, 6 June 2014 at 00:34:19 UTC, Jonathan M Davis via
 Digitalmars-d wrote:
 And like with them, it's impossible to use ref for this,
 because you can't use
 ref with variadic template arguments.

Wait what? void foo(T...)(ref T args) { args[0] = 42; } void main() { int x; foo(x); assert(x == 42); }

Well, that's new then. You didn't used to be able to do that. I clearly missed that change. Thanks for the correction. I'd still use pointers in this case though, since it's clearer and consistent with existing code like getopt. - Jonathan M Davis

And strongly system.

This alone is absolutely blocking objection against pointer-based decomposition in my opinion. Liked simple design with returning struct most.
Jun 06 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 05 Jun 2014 23:54:49 +0200
Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I'm just saying that encouraging that kind of
 return-by-weakly-typed-pointers-with-string-selectors interfaces
 is /not/ a good idea; there are other, much better, options in D.

There's no weak typing here at all. The closest that there is to weak typing is the fact that it will accept pointer to any integral type which risks overflow if you select a type which is too small to hold the value. Everything else about this is strongly typed. Accepting strings as template arguments is something that core.time and std.datetime do in a number of places, and it has proven to be extremely useful and flexible - and it really doesn't have anything to do with types - be they weak or strong. It's used to indicate which units a value is intended to represent. Those strings are the same across core.time and std.datetime and template constraints do a wonderful job of protecting against invalid string values. Remember that they're _compile time_ values, not runtime, so any problems with them are caught when you compile your code. It's not like any of this is being done dynamically. It's taking advantage of D's wonderful metaprogramming capabilities. And if you don't like the overload which accepts pointers, then just use the overload that returns a struct (which then has member variables with the same names as the strings, all of which are longs). split as presented is incredibly straightforward and simple to use - and it's quite type safe - whereas what you're suggesting is far more complicated and to no real benefit as far as I can tell. - Jonathan M Davis
Jun 05 2014
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 05 Jun 2014 18:15:11 -0400
Steven Schveighoffer via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 Respectfully disagree, the API looks very good to me. And decidedly
 not C-like.

It's not even _possible_ to write a function like this in C or in C++98 (though - though maybe C++11/14 can). I don't know of any other language where a function like this can exist. I think that it's actually a great example of what you can do with D, and it's implementation not shows off a number of basic features, but it's simple enough that it's not at all hard to understand in spite of how fancy what it's doing is. I've never seen another language that had metaprogramming language capabilities as simple and powerful as this. Sure, you could argue that having the function take ref instead of pointers would be better (though that's debatable) and that using pointers instead of ref is too C-like, but since you unfortunately can't actually have variadic template arguments which are ref, we're stuck with pointers for that overload of split even if we would have wanted to do it differently. getopt is in the same boat, so it's already doing what some other important D functions do. - Jonathan M Davis
Jun 05 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jonathan, every one of your postings starts a new thread rather than staying in 
the one you reply to.
Jun 05 2014
parent reply "Kagamin" <spam here.lot> writes:
It happens regularly with posts going through mailman.
Jun 06 2014
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 6 June 2014 at 08:58:44 UTC, Kagamin wrote:
 It happens regularly with posts going through mailman.

It happens "sometimes". Jonathan's post have been doing it *every time* in the last couple of days...
Jun 06 2014
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 06 Jun 2014 09:21:56 +0000
monarch_dodra via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Friday, 6 June 2014 at 08:58:44 UTC, Kagamin wrote:
 It happens regularly with posts going through mailman.

It happens "sometimes". Jonathan's post have been doing it *every time* in the last couple of days...

Hmmm. It looks like it works fine when I post from home but consistently gets screwed up when I post from work. I have to interact with the web interface for my e-mail client at work for sending messages, because stupdily, SMTP is blocked (so sending from my local client doesn't work), and something about that process seems to have recently stopped working properly with threading. I may have to stop posting from work for the time being. :| - Jonathan M Davis
Jun 06 2014
parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 6 June 2014 at 09:47:24 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
 I may have to stop posting from work for the time being. :|

I understand it may not be ideal from the perspective of your usual NG workflow, but maybe the forum interface could offer some relief? -Wyatt
Jun 06 2014
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 06 Jun 2014 12:49:42 +0000
Wyatt via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Friday, 6 June 2014 at 09:47:24 UTC, Jonathan M Davis via
 Digitalmars-d wrote:
 I may have to stop posting from work for the time being. :|

I understand it may not be ideal from the perspective of your usual NG workflow, but maybe the forum interface could offer some relief?

Maybe, but the problem is that it's my e-mail client (via IMAP) which keeps track of everything that I have and haven't read. Interacting with the forum at work and my e-mail client at home wouldn't work very well, though I could probably dig through the forum and figure out which post it is that I'm trying to reply to and reply in the forum. I'm sure that I can figure something out, but the situation is definitely a bit of a pain. I've never understood why my employer's IT department insists on blocking _outgoing_ ports. It's _really_ annoying to the employees and doesn't help with security except against machines which are already infected with something. It took us ages to get them to even open the outbound ssh port. - Jonathan M Davis
Jun 06 2014
next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 6 June 2014 at 13:04:24 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
 It took us ages to get them to even open the outbound ssh port.

Oh? This is promising. Sounds like it's time to set up a reverse SSH tunnel! ...Not that I have all sort of experience with these because of WebSense's bizarrely overzealous tendency to block URIs with "blog" in them, regardless of the useful documentation they might have. What ever could you be talking about? (orz) -Wyatt
Jun 06 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Friday, 6 June 2014 at 13:04:24 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
 I've never understood why my
 employer's IT department insists on blocking _outgoing_ ports.

Blocking outgoing SMPT is a good and easy practice to block spam.
Jun 07 2014
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 07 Jun 2014 20:24:39 +0000
Kagamin via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Friday, 6 June 2014 at 13:04:24 UTC, Jonathan M Davis via
 Digitalmars-d wrote:
 I've never understood why my
 employer's IT department insists on blocking _outgoing_ ports.

Blocking outgoing SMPT is a good and easy practice to block spam.

Only if you care about spam _leaving_ your network, not entering it. I don't know how much an IT department should worry about that or not - I wouldn't have thought that it would be a real concern, but maybe there's a reason to worry about that. However, as an employee, it's _extremely_ annoying, and it costs me time (and thus costs the company mony) every time I need to send an e-mail with a personal e-mail account rather than my corporate one. - Jonathan M Davis
Jun 07 2014
next sibling parent reply "Kagamin" <spam here.lot> writes:
Of course sending spam is worse than receiving. You can try 
secure SMTP, if your server supports it. AFAIK, it was a solution 
to spam problem, so it shouldn't be blocked.
Jun 07 2014
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 07 Jun 2014 21:07:49 +0000
Kagamin via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Of course sending spam is worse than receiving.

If you say so. I don't know why you'd really care beyond the fact that it's rude. Concern about getting blocked by other SMTP servers?
 You can try secure SMTP, if your server supports it. AFAIK, it was a
 solution to spam problem, so it shouldn't be blocked.

Oh, I'm trying to use secure SMTP - not SMTP over port 25, but the IT department blocks pretty much _everything_. They even block _NTP_, which is just plain stupid IMHO. They pretty much seem to have only opened a port if a VP complained loudly enough for long enough. So, you're lucky if much of anything beyond port 80 or 443 works. - Jonathan M Davis
Jun 07 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
Or better - some mail servers provide additional smtp port, which 
handles only authenticated client-server smtp, it shouldn't be 
blocked either (spamers use unauthenticated server-server smtp).
Jun 07 2014