So someone unclear on the $_[KERNEL] concept needed some help with it
on IRC. They wanted to call a function that set a delay in the
current session, but they didn't understand that $_[KERNEL] is a
reference to an object (a singleton) and didn't magically appear in
called subroutines.
For example:
sub event_handler {
my ($kernel, $heap) = @_[KERNEL, HEAP];
... some other stuff here ...
set_a_delay();
}
sub set_a_delay {
$_[KERNEL]->delay(woozle => 12); # or whatever
}
The obvious solutions are:
1. Pass $_[KERNEL] into set_a_delay.
2. Use $poe_kernel in set_a_delay.
3. Use &set_a_delay to pass @_ in automagically.
Randal asked why we had $_[KERNEL] anyway if it's a singleton. He
asked why we couldn't use POE::Kernel->delay() instead. I brought up
legacy reasons:
1. Very early versions of POE ran multiple kernels.
2. Nobody's patched POE::Kernel (et al) to ignore $_[0] and use
$poe_kernel.
In retrospect there's also:
3. It's more grief to type POE::Kernel than $poe_kernel, at least on
my dvorak keyboard. :) Although it's probably less grief than
$_[KERNEL] or my $kernel = $_[KERNEL], and those are more common.
4. I've always been aesthetically displeased by the idea that some
of POE's runtime context might come from somewhere other than the
handler parameters.
So I've been historically against it, but we're entering a Brave New
World of POE's design, where I try to remain calm while discussing
design with hundreds of strangers. Cool! And scary, but here we are.
Making POE::Kernel methods dual-mode amounts to ignoring $_[0] in them
and using the singleton $poe_kernel variable, already extant in the
package. So there's no performance penalty to support all three of
these idioms:
$poe_kernel->delay(...);
$_[KERNEL]->delay(...);
POE::Kernel->delay(...);
In fact, the run() method recently did this, making the mysterious
(hey, where's that variable from?) $poe_kernel->run() into a more
palatable POE::Kernel->run() for the OO weenies who don't like the
fourth wall pierced.
Thinking things through, it also allows POE::Kernel to possibly export
functions that look and feel like built-ins. So we get the
possibility of a fourth idiom:
use POE::Kernel qw(delay);
delay(...);
This idea squicks me out, but I figured I should mention it.
--
Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
