Re: Better ways than call()

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.

--=20
Rocco Caputo <[email protected]>

> On Nov 9, 2015, at 08:06, john <[email protected]> wrote:
>=20
> The POE::Kernel documentation indicates this for call():
>=20
> 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.
>=20
> 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.
>=20
> John