On Fri, 2002-05-24 at 13:14, [EMAIL PROTECTED] wrote:
> On Fri, May 24, 2002 at 10:34:36AM -0400, Peter Chen wrote:
> > On Fri, 2002-05-24 at 00:02, Rocco Caputo wrote:
> > > Postbacks are cumbersome for message passing in larger programs.
> >
> > I also notice that postbacks decrease the transparency of the messages
> > being passed. When posts are used, it's straight forward to tell what
> > messages are passed back to the sender. Postbacks on the other hand
> > mask this information.
>
> I wouldn't agree to this. They enable the posting session to have
> local communication ends. They don't need to know about the receiving sessions
> interface (except the sender-supplied arguments). I would consider this as
> a good thing. The bad side is that they are not powerful enough. You can
> use them in good ways, but they don't automatically steer developers in this
> direction.
It's not clear to me which approach has a clear advantage. That's why I
asked the question. :-) In practice, I tend to use postbacks more often
because I do not need to keep track of the sender as you described.
However, in some ways, postbacks are somewhat awkward.
> > Another idiosynchrocy about postbacks that often caught beginners is the
> > arguments (in fact, this was a bug in the example program fragment I
> > included, *sigh*). In the event handler, $_[ARG0] is [@state_args] and
> > $_[ARG1] is [@event_args] instead. This is very different from simple
> > posts.
If I were to use postbacks:
$postback = $session->postback("got_response");
$kernel->post("worker", "work_request", $postback);
The event handler for "got_response" may look like
sub got_response {
my ($state_args, $event_args) = @_[ARG0, ARG1];
# ...
}
But that means, I can no longer write
$kernel->post("got_response", @result);
So, I often end up with
$callback = sub { $kernel->post($session, "got_response", @_); };
$kernel->post{"worker", "work_request", $callback);
Pete
