Front page | perl.perl6.language |
Postings from January 2001
"Stephen P. Potter" wrote: > > Why do we have to worry about changing time()? There's a real parallel > between sleep() and alarm(), so we would want to do both if we did either, > but time() really has no relation to them. > > Or, should we just implement usleep() and (for lack of a better name) > ualarm()? One thing that was discussed on the archives that I sent out was introducing a parallel mjdate() (or isodate() or whatever) which gave access to the internal means of maintaining time in Perl. Then Perl's internal clock could be sub-second ticks since 4152 BC, Modified Julian, etc, etc. So time() could remain unchanged (from a language/user perspective, at least), but sleep() and alarm() could use the internal sub-second methods of timekeeping to DWIM. The user gets sleep(0.5) and time() is still epoch seconds. But the big problem is that there's a lot of stuff that's based off of time() right now, like stat(), lstat(), etc, etc. When you think of the cascading effects of changing Perl's timekeeping it gets really, really sticky. If the internal timekeeping were changed, one thing that's apparent from the discussions is that there would *have* to be a core way of providing exactly what time() does currently or lots of stuff would break really badly. Someone can certainly chime in if they see an easy way around this, but as I recall there was little disagreement on this point. -NateThread Previous | Thread Next