> Maybe I skimmed to fast through the doco, but I had to read the code to
> find the arguments that were pasted to the postbacks.
unless you have an ancient version of the ::Child you should have seen this:
Event handlers are passed two arguments: ARG0 which is a reference to
the component instance being used (i.e. $self), and ARG1, a hash
refer-
ence containing the wheel id being used (as wheel) + values specific
to
the event. Callbacks are passed the same arguments but as @_[0,1]
instead.
or maybe that is not sufficient. I will think about rewriting it in greater
depth.
> rather then having to hold on to the object reference
huh? what's wrong with keeping the object? why would you prefer to post
messages to an internal session when there is a perfectly good abstraction
behind $o->run()?
> I can't currently
I suppose I can always just add a method to return the name of the internal
session so you can send it messages directly... but I don't get it.
> In my mind you shouldn't even have an argument like this,
if you don't tell ::Child what session to throw its events at, how are you
supposed to get callbacks?
> it should be set with the postback. Or it should use $_[SENDER].
*ekkis feels clueless
> POE::Component::Child->spawn
what are you looking at?? ::Child doesn't offer spawn()!
> [EMAIL PROTECTED] is a proposed way of saying "event
> command_error in session monitor"
you can currently ask that events be sent to the session indicated by
"alias"
> Note these are much more complex use scenarios then PoCo::Child
> currently allows.
perhaps you'll need to elaborate because from the posted code I don't see
anything you couldn't do with ::Child
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 10:56 AM
To: Erick Calder
Cc: [EMAIL PROTECTED]
Subject: RE: New PoCo Guidelines
On 29-Jul-2004 Erick Calder wrote:
>> The doco for both is thin.
>
>:( I thought I did a pretty decent job at doc for ::Child... if you have
>any suggestions I'd be happy to consider them.
Maybe I skimmed to fast through the doco, but I had to read the code to
find the arguments that were pasted to the postbacks.
>
>> PoCo::Child has the strangely named parm "Alias", which doesn't
>> set the alias of the component but the alias of the session
>> postbacks are posted to.
>
> why would you want to set the alias of the component's internal session
> when you are never going to address it?
You see, I do expect to address it. Looking at your code, I see that it
is designed to handle executing concurrent commands. So I expect to be
able to do
$poe_kernel->post('Child' => 'run', 'lpr -P lp1');
or equiv from my code, rather then having to hold on to the object
reference. I can't currently, unless I write a wrapper session around the
PoCo::Child object and session.
> and what's strange about naming it "alias"? what would you name it?
Most other components use that param to name their alias. At least one
other person was supprised at PoCo::Child's behaviour in this regard.
> what would you name it?
This is part of what I want the PoCo Guidelines to describe. In my mind
you shouldn't even have an argument like this, it should be set with the
postback. Or it should use $_[SENDER].
IMHO, the interface to PoCo::Child should be multiplexed. That is :
POE::Component::Child->spawn(Alias=>'runner',
StderrEvent=>'[EMAIL PROTECTED]',
ErrorEvent=>'[EMAIL PROTECTED]');
## [EMAIL PROTECTED] is a proposed way of saying "event
## command_error in session monitor"
## Later, in session Zip
$poe_kernel->post(runner=>'run', Command=>'lpr -P lp1',
StderrEvent=>'lpr_error');
## lpr_error in session Zip would be called if there was text on
## stderr
## and elsewhere, in another session even
$poe_kernel->post(runner=>'run', Command=> 'pgpv',
StdoutEvent=>sub { }, # ignore
StdinEvent=>sub { return shift @text },
StderrEvent=>'[EMAIL PROTECTED]');
Note these are much more complex use scenarios then PoCo::Child currently
allows. The simplified form could maybe be done with
$run=POE::Component::Child->spawn(Postback=>$_[SESSION]->ID);
$run->run('ls -lr');
and now the current session will receive all the events with the default
names.
>> POE::Component::Base
>
> I love it. and now that we're talking about this, could we shorten the
> base name? I have components like POE::Component::Player::Mp3 - which
> is entirely too long! Could we at least do POE::Co?
Agreed! However, I'd propose that only components that meet some
guildlines would be allowed in that name space.
-Philip
