On Tue, Nov 12, 2002 at 09:40:35AM -0800, Erick Calder wrote:
> > I like the simplicity of this syntax.
>
> me too. I still prefer $kernel->yield() as it is simple, but certainly
> kernel()->yield would be better than $message->kernel->yield()? i.e. where
> "better" == "shorter" - me lazy and hate to read/type > I have to :)
>
> > Rather than patching Session.pm, I recommend subclassing it in the
> > same vein as http://poe.perl.org/?POE_RFCs/Named_state_parameters
>
> why not patch Session.pm? a switch in the create() to enable it seems this
> functionality would make more sense. in fact:
>
> options => { parameters => $my_choice }
> where $my_choice could be "message" | "function" | "normal"
>
> .... that way I don't have to select which package I want. I much prefer to:
>
> use POE::Session;
>
> than:
>
> use POE::Session::somethingorother;
>
> ....it's just simpler to think about. anyway, just my tuppence.
I like the options syntax, but I think combining all possible calling
conventions into Session will turn it into a monolith. One compromise
would be to add the syntax while still using subclasses:
options => { subclass => $my_choice }
where $my_choice could be "MessageBased" | "Function" | default=none
Internally, the constructor can load the subclass module as necessary
and bless the new session into "POE::Session::$my_choice" rather than
POE::Session.
Combining all calling conventions into one class also introduces at
least one more runtime condition in some of POE's hottest code.
Dispatching events through a Session subclass would avoid the extra
cycles.
-- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
