> 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