At 11:01 -0400 2000.09.14, Andy Dougherty wrote:
>On Thu, 14 Sep 2000, Chris Nandor wrote:
>
>> There's also the possibility of time accepting an argument, where 0 would
>> be perl's time and 1 would be native time, or something.
>
>Now that's a clever idea. Hmm. I think I like it as a solution to the
>specific issue at hand better than the proposed time()/systime() pair.
>I think I'll "borrow" your suggestion for a longer posting on
>perl6-language :-).
Be my guest. I am not favoring one solution or another, just throwing out
ideas. I had tossed around the idea of drawing up several competing RFCs.
:-)
BTW, Nat noted that a moratorium on RFCs is FAST approaching, that Larry
will make his draft feature set on Oct. 1, and his final on Oct. 14, so get
any new RFCs in now. See http://use.perl.org/ for links to what Nat said.
>On the other hand, I'm not sure I like it too much as a general solution
>to the broader portable vs. native issue, since other functions with
>arguments can't be handled so cleanly.
True.
>Yes, I know it's very very unfair to take your time() suggestion and try
>to apply it to a question like "Should unlink() on VMS unlink all previous
>versions (i.e. like a command line PURGE) or should it behave more like
>DEL and only delete the latest version?
>
>But the unlink() question is also a valid one with many of the same
>underlying issues. I'm currently trying to think about how to encourage
>us collectively to handle similar issues in similar ways.
Well, I don't think it is entirely unfair. Also, what values do -T and
stat() return? Well, -T is not so much of a problem as long as the epoch
is still in seconds, but stat() sure is a problem. We could make stat take
an optional second parameter. I don't think any other builtin would have
the problem, but what about modules like Time::Local?
--
Chris Nandor [EMAIL PROTECTED] http://pudge.net/
Open Source Development Network [EMAIL PROTECTED] http://osdn.com/
