On Wed, Jan 31, 2001 at 09:53:23AM -0200, Branden wrote:
> [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.
time() is a very simple call, only a few lines of code in the Perl
source, without much overhead. It's also used quite a lot. There's
hardly anything to gain by removing it, it will break a fair number
of programs, and the alternative requires you to pull in a module.
That doesn't seem a fair trade-off to me.
> 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!
The point of me was that with the given code, you *don't* need to remember
you are programming in perl5 or perl6, and get the same functionality.
If I would think typing 'use Time::Local "time"' isn't too much to ask to
get basic functionality, I'd be using Python. Things just being there is
a feature of Perl. The "lean-and-clean" market is well covered by other
languages.
> > 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.
It's not complex, but it probably has a lot more overhead than it gains
from not being there. Perl6 doesn't have to be 100% compatible with perl5,
but that's not an invitation to break everything that can be broken.
> > 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.
To make a simple loop, Perl offers you: for, foreach, while, until,
{redo}, map, grep, //g, goto and recursion. Which 9 of them do you
propose to drop from the language so Perl causes less confusion?
There Is More Than One Way To Do It is an official Perl slogan, and
now you are claiming this a *bad* thing? Oh my.
> 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!
*blink*
Are you claiming the use of time() is dead? Or that stability is a bad
thing?
Abigail
