Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Better ways than call()

2 views
Skip to first unread message

Rocco Caputo

unread,
Nov 9, 2015, 9:00:02 AM11/9/15
to p...@perl.org
Hi, John.

There's no requirement to store everything in $_[HEAP]. Data that must be accessible outside a session can be stored somewhere else.

For example, if you're using object_states to handle events, each call gets a reference to the object: $_[OBJECT]. So you can store data particular to the object in the object handling events. Normal accessors can be used to access it. This gets tricky fast since mutators and other methods that initiate actions in the underlying session may still involve post() or call(). POE::Component::Resolver does the tricky parts, but it doesn't do the simpler thing you need.

There could be a shared dictionary for accessible data. This could be as basic as a hash in a scope outside the session. The %users hash in http://poe.perl.org/?POE_Cookbook/Chat_Server is this sort of thing. I prefer something like this when peer sessions must coordinate their work.

External code that requests work from a session can also pass in a reference where state will be stored. This could be a reference to some structure both the requester and the worker agree upon. I prefer to use objects for this, since the contract between requester and worker can be encoded and enforced in methods.

--
Rocco Caputo <rca...@pobox.com>

> On Nov 9, 2015, at 08:06, john <jo...@tonebridge.com> wrote:
>
> The POE::Kernel documentation indicates this for call():
>
> call() returns the value returned by the EVENT_NAME handler. It can do this because the handler is invoked before call() returns. call() can therefore be used as an accessor, although there are better ways to accomplish simple accessor behavior.
>
> What are some of those ways? I tried a simple subroutine but don't seem to have access to things like the heap. I guess I could pass those in but than things don't seem as simple anymore.
>
> John

0 new messages