Jarkko Hietaniemi wrote:
> As I said the problem isn't the p52p6 doing that kind of transformation.
> The problem is someone familiar with perl5 writing code in perl6:
>
> if (my $fh = open(">/tmp/$$".time())) {
>
> and later something crashing and burning because some other place expects
> to find a filename of the form /^\d+\d+$/, or someone printing into log
files
> like this
>
> print LOG time() . ": gorkulator borked. Please investigate."
>
> and someone splitting on /\./, etc.
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());
}
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...
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...
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!
- Branden
P.S.: Nathan, on re-reading RFC 48 I spotted out that comparison of dates
isn't mentioned. Of course there's a section on ``Date arithmetic'', that
talks about -, I think mentioning < and > is worth it.
