[EMAIL PROTECTED] wrote:
> > 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.
Because with a better built-in that handles fractions of second (if that's
ever desired, and I guess it is), time() would be deprecated and could
be easily reproduced as int(now()) or anything like it. It could be in
a module so that anyone that still wants to use it can find it there. This
was suggested in RFC 48, that proposes deprecation of localtime and gmtime,
in favor of the new date and utcdate, and put the old ones in Time::Local.
> > change:
> > : if (my $fh = open(">/tmp/$$".time())) {
> > for:
> > : if (my $fh = open(">/tmp/$$".int(now()))) {
>
> > change:
> > : print LOG time() . ": gorkulator borked. Please investigate.";
> > for:
> > : print LOG int(now()) . ": gorkulator borked. Please
investigate.";
> 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.
>
The point was, if you're writing new code, you only have to remember that
when you
used to have time() in perl5, you should have int(now()) in perl6. That's
simple
and doesn't hurt, IMO. If you like time() and think you can't live without
it, and
think `use Time::Local "time"' is too long to type, then you should better
stick
with perl5!
> 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?
>
Hello... I guess the whole perl6 thing was about breaking compatibility,
wasn't it? At least, I take for sure we'll have a p52p6 translator to
translate old code. And for one such translator, importing things from
Time::Local or even replacing every occurrence of `time()' for `int(now())'
or whatever is chosen to replace it, isn't complex at all.
> 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.
More than one function to do the same thing is A Bad Thing, IMO. It only
causes confusion.
If a change of mind when writing new software is too much a burden, then,
I say it again, we should stick with perl5! As Jarkko always quotes:
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
If old code and old-code thinking are the only thing that prevents us to
change time() or move it out of CORE, then I believe we should do it yes!
- Branden
