Re: standard asynchronous deferred-to-result syntax RFP
On 14 Jul 2005, at 13:16, David Nicol wrote: I have uploaded asynchronous::universal::ready and asynchronous::universal::set_callback to CPAN. They are both entirely trivial packages with a mess of documentation. The idea behind them is to support asynchonous frameworks in which the immediate result of passing away a message is a placeholder object with a ready method that will return a false value until its result message comes back, at which time the placeholder upgrades itself to a result. I took a look at them when you loaded them to CPAN but couldn't quite figure out how they would fit into something like qpsmtpd's async framework - we don't poll a bunch of objects for readiness state - we have to let the OS kernel notify us through the epoll/poll/kqueue framework. Matt.
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
On Mon, Aug 07, 2000 at 01:44:28AM -0500, Jonathan Scott Duff wrote:
On Sun, Aug 06, 2000 at 11:07:02AM -0700, Russ Allbery wrote:
Basically, you don't want to go anywhere near this mess; it eats people.
I agree.
I see two reasonable options to go with instead. One is to just use a
binary flag that says use UTC or not; this is the simplest and most
reliable to explain. The other is to allow a timezone offset; this
doesn't deal with daylight savings time and historic time zone changes,
but it provides enough power for most of what people want to do and if you
want to deal with the rest you have to deal with time zone naming.
I agree completely with Russ, and I would further state that I don't
want this Cdate feature in the core. Dates, times, timezones, leap
seconds, month and day names, localized formats, etc., are too
complex. No one here has thought out the complexity enough to say
"this is what Perl will support from now on".
Currently, there isn't even an adequate (in my opinion) module on CPAN
that gives dates a proper abstract interface. Time::Object may be
okay as a lightweight localtime/strftime interface, but it does not
support date, as opposed to time/date, arithmetic, or rather, it
mis-supports it.
Well its called Time::Object, not Date::Object for a reason... :)
Since we really don't understand dates here, I don't want us commiting
to a certain interface without a `use' directive in the program.
Distribute Time::Object as a standard module, but keep it a module,
and don't force its quirks on people. Certainly, don't force the
complex, quirky, and untested interface being developed here now on
anyone without a long, patient discussion period.
This makes an incredible amount of sense. We could even let the user
specify a coderef to a sub that implements their own particular
timezone oddities. (i.e. a sub to tell date() what the TZ offset is)
Gross. Put it in a module.
While I think Time::Object is a really great module, and following these
discussions I'm thinking of adding a date() function to it, I'm actually in
total agreement with John here. Times and dates are something that should be
supported _simply_ by the core of Perl, and more extensively in an external
module. I'd be very happy to see the Time::Object in core perl as a module,
but I'd hate to see it as the _only_ interface to dates. And the extensions
being proposed here just seem like bloat to me. And John is totally correct:
Time::Object attempts to do some datetime arithmetic, but doing this sort of
thing properly for dates alone is really a tough nut to crack, and not
something that we need put in the core. There are modules out there to do
this sort of thing, lets keep it that way (or improve them enough to put in
core).
The only part of this proposal that I like is Damian's WANTHASH extension
which would allow localtime{'day', 'month', 'year'}.
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. There are lots of
simple scripts that use localtime that I wouldn't have thought people will
want to run through the p5top6 conversion script just to get running on a
newer perl. (and then theres the issue of how you detect the addition of
1900 to the year even using the B::* stuff).
BTW: Since I'm not subscribed to p6-lang (I think you guys would kill my 64k
link!), I'd just like to say that just because strftime() is a unix-ism or
POSIX-ism, does not mean that its bad. Programmers know strftime, they've
heard of strftime, lets not try and confuse things by doing a "Java" and
inventing our own new date formatting functions with new format specifiers.
Perl is not about NIH.
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
Re: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da
On Tue, 8 Aug 2000, Nathan Wiger wrote:
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).
Thats the idea...
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.
Well OK, I concede... Lets see how Larry takes to these ideas. Judging by
the fact that this is something he originally suggested, I'm guessing he
might be into it.
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.
All I can say to that is, ugh! I don't want to see Perl6 be so
fundamentally different to perl5 that I have to translate every single
script. I want some better stuff, but a new language is not what I'm
looking for.
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.
I take the Cozens stand on this: I don't like "alternatives" if they just
re-implement something that works already.
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
Re: date interface (was Re: perl6 requirements, on bootstrap)
On Thu, 3 Aug 2000, Hildo Biersma wrote:
Reply
I'd either leave that as (localtime)[3,4,5] (please read the man page for
Time::Object), or understand that there's absolutely no need to separate
off the variables like that in an object oriented interface:
Ah, but we could make the language support this:
localtime-{'day', 'month', 'year'}
in hash-slice fashion. If functions could distinguish between
'wantarray' and 'wanthahs' this would be easy to do. And certainly, for
all the getpwXXX and getnetXXX functions, it seems like the right
apporach to me.
Define a use case, and I might be more interested. But to me theres
absolutely nothing you've specified that really isn't in the language
right now. In fact I could export some constants from Time::Object so that
you can go:
(localtime)[DAY, MONTH, YEAR];
I'd be interested also in a language extension that allowed you to remove
the parens from that expression: localtime[DAY, MONTH, YEAR] (and see the
same sort of thing apply to stat() too), but that has been mulled over
several times on p5p and I think the general consensus is that its too
hard to parse and even *more* context sensitive than before - something I
thought we were supposed to be thinking very carefully about in this
re-write.
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
