Nicholas Perez wrote:

Okay, I am no POE internal genius, and perhaps I am using call() inappropriately (inter-session), but I find a lot of convenience in using a separate Session to hold data that needs to be synchronized/serialized.

You should be using an object or global structure, or the heap.


Not only that, that there is also even greater convenience in that fact that call() returns something.

The proposed Session->call() method still provides the return value of the state invoked.


I don't need to provide or kludge around with return events for data that I need immediately for critical paths. Now some may argue that I just need to maintain a separate class or object and make method calls to that to access that data, but then I run into the problem of making sure all the Sessions that I want to be able to access that object, all have that object.

Simple! Create the object in the package you create your session in. If you need various sessions to use the same data, then make your object store its neccesary data in a package global, so your object has object-persistent data, that is, data for each instance of itself in its blessed referrence, any data that needs to not be on a one-on-one basis and must be accessable from all instances of the object, you keep in globally scoped package variables.


With a stand alone Session, I can simply reference it by its alias and make call()s to it.

Thats slow ;)


Now maybe the negatives outweigh my laziness, but in my not so knowledgeable opinion, having a specific Session filled just with synchronized or critical functions just makes sense in the cases that I have applied it.

Not everything needs to be an event, or so Rocco once told me.



Just my two cents on the matter. I found a practical application for what everyone seems to call ugliness.

The only real problem with trying to design an efficient program the way you mentioned is there is alot of imposed context switching by your design that could be avoided. Its all behind the scenes and happens within the POE::Kernel itself, so this overhead is imposed by the design itself.


If you're really only storing data, you really should use an object OR package in the ways I mentioned above. Atleast, if you have any desire to maintain efficiency.

Now here I must note, that I didn't come up with the idea of removing inter-session calling all together. I found the idea on the wiki. Now I'm not gonna name names, and I'm not gonna drag others in, because I am a proponent of the idea. I think inter-session calling breaks POE Design patterns. Forcing inter-session communication to be done via post()ing helps force people using the POE Framework to let POE do its thing, and stops people from doing things like creating sessions just for the sake of creating sessions.

- Scott

Reply via email to