I can see how you would frequently want to design states that could be
invoked in both blocking and non-blocking mode.
For example, imagine you had a session acting as a http client. You
might want to design the request() handler to work in both models:
1) [NON-BLOCKING] You could post a request event to the session, which
would perform the request and then send an event back to let you know
when it is done, or if it errored out.
2) [BLOCKING] You could use call instead of post, if you insist on
performing the request immediately and getting the results back, in
which case there is no reason to mess with the http client session
sending an event back when it can simply return the web page (or error
code) as the return value of the call.
But, how do you elegantly implement that request method in such a way
that it knows what the caller wants it to do without additional "mode"
parameters (which are ugly)?
I suppose the blocking/call() form is akin to calling a function as
opposed to sending an event, and arguably shouldn't be supported in the
event-driven model of POE, but it is convenient sometimes. :)
-ofer
- post/call dual interface design Ofer Nave
- Re: post/call dual interface design Rocco Caputo