> 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. -----Original Message----- From: Rocco Caputo [mailto:troc@;netrus.net] Sent: Tuesday, November 12, 2002 8:40 AM To: [EMAIL PROTECTED] Subject: Re: Pseudo Lexical State Parameters On Mon, Nov 11, 2002 at 06:00:52PM -0600, Garrett Goebel wrote: > I noticed at: > http://poe.perl.org/?POE_RFCs/Lexical_state_parameters > > That there was a desire to: "Turn @_[KERNEL, HEAP, etc.] into regular > variables, somehow" > > Attached and also inlined at the bottom, you'll find a first attempt patch > against Session.pm. If you like, I can easily whip up a similar patch for > NFA.pm > > What it does, is to push an anonymous array of parameters onto a stack > before invoking a state, and then pop if off afterwards. There are a > complimentary set of subroutine declarations which are pushed out via > "import" which allow you to access the parameters at the top of the stack as > so: > > $_[OBJECT] -> object() > $_[SESSION] -> session() > $_[KERNEL] -> kernel() > $_[HEAP] -> heap() > $_[STATE] -> state() > $_[SENDER] -> sender() > $_[CALLER_FILE] -> caller_file() > $_[CALLER_LINE] -> caller_line() > @_[ARG0..$#_] -> args() > > I continue to pass all the test I previously passed on Win32 after the > application of this test. > > enjoy. [patch] I like the simplicity of this syntax. Rather than patching Session.pm, I recommend subclassing it in the same vein as http://poe.perl.org/?POE_RFCs/Named_state_parameters Will the lexical @params be clobbered by multiple sessions if we ever get them running in separate threads? -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
