> While I think Time::Object is a really great module, and following these
> discussions I'm thinking of adding a date() function to it
Aaah! Please don't. :-) Name it something else, por favor (or at least
wait until this is finalized and make the interface the same).
> date arithmetic...not something that we need put in the core.
I'm torn on this one. If it's efficiently done on objects, I think it's
really cool. However, it could be implemented really poorly and suck.
But I'd rather leave it in and let Larry decide to axe it (he suggested
it, after all...)
> The only part of this proposal that I like is Damian's WANTHASH extension
> which would allow localtime{'day', 'month', 'year'}.
That and returning an object in a scalar context. This is a key shift
I'd like to see in Perl 6 - embedding objects at a low-level and
translating them to strings only on demand.
> I'm also really aware that trying to change localtime in an array context to
> return the real year is going to be a very painful change.
The RFC doesn't mention localtime() for just this reason. The idea would
be localtime would be GONE in Perl 6, instead moved to Time::Local.
date() would replace it.
The syntax of localtime would remain identical. All the translation
script would have to do is add a 'use Time::Local' if localtime was
called, maybe outputting a warning message like
$ ./p52p6 mydatescript
localtime() no longer in core - use date() instead [importing
Time::Local]
> I'd just like to say that just because strftime() is a unix-ism or
> POSIX-ism, does not mean that its bad.
Yeah, this is a tough call. I agree with you, personally. When I see
strftime() I instantly know what it does. However, I think I've come up
with an alternative that's just as good. I encourage you to check out
v2, probably out by tomorrow. I think you'll like it better.
Cheers,
Nate
