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