First, yeah. Squick city.

On Sun, Feb 22, 2004 at 09:31:41PM -0500, Rocco Caputo wrote:

> 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.

Somebody's lack of clarity is hardly call for change.

Many people have a very hard time getting over the $_[BLEH] idiom.
Well, maybe they shouldn't be trying to program POE. All the
docuemtnation, and the examples, the cookbooks, the wiki, alllllll
point to the use of:

my ($kernel, $session, $heap) = (@_[KERNEL, SESSION, HEAP]);

I originally read this message to be an RFC about removing the actual
$_[KERNEL] parameter in favor of using POE::Kernel, or $poe_kernel, or
whatever. I have since changed my opinion -- you couldn't seriously be
proposing that, right?

Changing this to require POE::Kernel (in stead of $_[KERNEL]) would
break  all kinds of my own personal code, certainly all of at least two
of my employers' code, and all kinds of examples and documentation.

There is nothing wrong with the idiom other than a few peoples' failure
to understand it.

Screw em.

> The obvious solutions are:

>   1. Pass $_[KERNEL] into set_a_delay.

Implicit. Baaad.

>   2. Use $poe_kernel in set_a_delay.

This is reasonable enough, but silly.

>   3. Use &set_a_delay to pass @_ in automagically.

There is already a ton of confusion about the '&' sigil, I really
dislike adding more to it.  It's one of those cargo cult things that
really upsets me.

> 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

What is so damn difficult about $_[KERNEL]?

>   2. Nobody's patched POE::Kernel (et al) to ignore $_[0] and use
>      $poe_kernel.

I suppose this doesn't really bother me.

>   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.

A cute snippet from my .vimrc:

ab mkh my ($kernel, $heap) = (@_[ KERNEL, HEAP ]);

I'm remembering a guy who showed up in #POE who was complaining about
how he had to use POE::This and POE::That and oh, horror,
POE::Component:ThisAndThat.  He wanted to just be able to say use
POE::Component::*.

After we got over our initial shock, we all began to tell him what an
idiot he was for wanting to write a source filter and all this other
stuff to save himself 70 characters from time to time. Hell, once, if
he's clueful enough to use a macro or templates.

"It is too long to type" is not now and has never been a good excuse
for change.

> 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.

Hopefully I haven't come across as un-calm. This really is not a good
idea, and I hope that comes across clearly.

> 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(...);

I really think I prefer this one. I see no reason to change the API to
accommodate people. It is established. We are talking about a 1.0
release because the codebase is becoming more mature, because we have
more users, because we're trying to keep the api consistent, et cetera.
Now is really not the time to be placating people with complaints about
semantics.

> This idea squicks me out, but I figured I should mention it.

This whole thread squicks me out already. :(

alex

--
[EMAIL PROTECTED]
Alex J. Avriette, Microsoft Certified Power User 
Give a homeless hax0r a home today! Run Debian!

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to