On Thu, Jun 21, 2001 at 07:35:58PM -0400, Rocco Caputo wrote:
>
> > So, how about also allowing a hash ref... or POE::Event object as a
> > specifier for event addresses?
> > {
> > to=>'some_session/some_event',
> > sender=>$_[SENDER],
> > reply=>'callback_event'
> > errors_to=>'error_event' # temporary monitor
> > }
>
> This looks like the POE::Message prototype I sent you a week or so
> ago. You're the unofficial interoperability (i14y?) pumpking, so I
> thought I'd run it past you first.
>
> This would also eliminate ARG0..ARG9 for many high-level things, which
> would make mjd happy. His comments on the subject prompted the
> ARG0..ARG9 depreciation in the TODO file (still only in the "hey, this
> could be a good idea" phase. no scary breakage yet!), and ultimately
> POE::Message.
in an object layer, association's objects can have roles (or you could say
they subscribe to specific interfaces). this would put events in real
context, since they could be validated or parsed accordingly.
of course this is possible without that extra context. but not as good.
associations could be held up across kernel boundaries. i could name
a _lot_ of advantages besides this one. it sounds wrong but proper reference
handling would solve most of the call, postback, alias problems. and some
more as well.
if you got roles, you have defined interfaces and poe really knows about
them. events can be checked, you can really link event consumers/subscribers,
... ARGx would go away as a side effect. although changing parameter format
from a simple array to something else is probably not needed.
supplying implementations for design patterns gets a lot easier ..
> POE::Message would also work in stock POE. I imagined adding hooks to
> the alias/id resolver to pass messages to unknown destinations to a
> resolver/gateway component, if such a beast was loaded.
the association itself could do it and would have all the necessary
information. additionally it would be divide and conquer for the gateway ...
> Can't depreciate call() in the general sense, sorry. Wheels need it.
> But as Artur has suggested before on the topic, we can depreciate and
> prevent it from working on any other session but the current one.
> Basically we'd remove the SESSION parameter and have it default to the
> current one.
then please implement something like the implicit postbacks i suggested.
it would remove the need for a lot of postback params in a lot of poe apps.
