On Tue, Jan 30, 2001 at 05:49:43PM -0200, Branden wrote:
>
> Well, then I propose the same of RFC 48: deprecate time() and create another
> name to refer to the number of seconds since (an epoch) with decimals for
> fractions of seconds. Maybe it could be called now() or timestamp(). Then
> time needn't be on CORE, and can be put together with localtime() and
> gmtime() on Time::Local or anything like it. It could be implemented as:
>
> sub Time::Local::time {
> return int(CORE::now());
> }
Why the urge to move it out of the core? Should perl6 be like Python,
where you first need to do a gazillion imports before you can do anything
useful? Say goodbye to quick one-liners then.
> Since there will probably a change of mind from programming perl5 to
> programming perl6 (as it will be probably more object-oriented, less
> unix-centric, etc.), I see no problem in telling perl programmers to
> change their implementations:
>
> change:
> : if (my $fh = open(">/tmp/$$".time())) {
> for:
> : if (my $fh = open(">/tmp/$$".int(now()))) {
> or:
> : my $fh = open("> /tmp/.$progname-$$-" . date(now(), '%Y%m%d%H%M%S'));
> : # creates the file /tmp/.myperlscript-56473-20010130173742
> : # just by looking at it, I can tell it was generated by "myperlscript"
> : # running by process whose pid is 56473, and was generated
> : # at 17:37:42, on january 30th, 2001.
> : # much easier to figure it out than than seconds from 1970...
If time() is there to stay, why bother changing the code? If you insist
on getting file names with year/month/date in them, you can do so now
using localtime(), and if you don't mind to have files with seconds-
since-epoch in the name, why would you mind when perl6 rolls along?
> change:
> : print LOG time() . ": gorkulator borked. Please investigate.";
> for:
> : print LOG int(now()) . ": gorkulator borked. Please investigate.";
> or:
> : print LOG date(now(), '%Y-%m-%d %H:%M:%S') # much better!
> : . ": gorkulator borked. Please investigate.";
> : # in a logfile, the clarity argument is even more valuable...
Write them as:
printf LOG "%d: %s\n" => time (), "gorkulator borked. Please investigate.";
or:
printf LOG "%s: %s\n" => scalar (localtime ()),
"gorkulator borked. Please investigate.";
or:
use POSIX;
printf LOG "%s: %s\n" => strftime ("%Y-%m-%d %H:%M:%S", localtime ()),
"gorkulator borked. Please investigate.";
and gain two things:
1) You get "much better!" without waiting for perl6 to roll along,
2) It doesn't matter whether time() returns an integer or a float.
> Well, at least that's what I think about time. This change wouldn't break
> compatibility, and changing the way we think about this function is a
> healthy thing for our programmer minds. Just because UNIX decided that
> its sleep function would return an int value, doesn't mean we have
> to follow it on our design!
Moving time() out of the core doesn't break compatibility? Changing the
return value of sleep() doesn't change compatibility? What *does* change
it then?
Let's not forget that Perl is a glue language. It heavily interacts
with its environment, other programs and is eager to network with
the outside world. Seconds since 1970 might be as arbitrary as any
other measurement, but that's irrelevant. What's relevant is 30 years
of code that produces and expects timestamps in seconds since 1970.
Deprecating time() in favour of some other arbitrary measurement is
absurd. It might makes sense to have some other functions giving units
since some point in the past next to time() though.
Abigail
