On (02/19 18:58), Scott wrote: > There are three answers to this. One is maintaining API sanity:
well, i'm not sure its sanity we're maintaining in keeping all these session-only methods in the kernel. its a small matter but its one that mildly irritates me. > The second is a weird form of optimization and specification: We > easily force the operation to occur on the currently active session by > making its interface the kernel, instead of having to perform sanity > checks to make sure the programmer isn't being a tard. i'm not sure how making its interface be the kernel allows for the dropping of sanity checks. the same work needs done. its just the that kernel is operating on $kernel->get_active_session and the session is operating on $self. in reality, while we can pretend that being kernel space means we're safer, really the same checks should be done regardless of whether or not we're in Kernel.pm or Session.pm. an actual reason to put these things in the kernel is that, for a while, before i put the data structures back in the kernel object, most of the information necessary to do this work was only available as lexically scoped variables in Kernel.pm. Session.pm simply didn't have access to the data necessary to do the work. And to be perfectly honest, i'm not sure it has proper apis to all the data necessary to implement yield/invoke/magical_go_sub or whatever else we're talking about. :) however, all this is just a big fancy semantic wrapper around _dispatch_event, _invoke_state and friends. so does Session.pm really need that info or can it just call the Kernel.pm methods that already exist? > The third is of course to limit what is required by the session, > making the session object an even more replacible thing. so there are two issues here. one: a pluggable Session framework. while a great idea for a lot of reasons, i think that its a lot farther off than we normally think. i also don't think this should be in the hands of mere mortals. there are huge concepts to consider in replacing Session.pm with your own home grown system and i wonder if we aren't setting ourselves up for a maintenance and support nightmare with this one. also, how often does one really need to replace session.pm? i have subclass of session.pm on cpan to extend it for someone rocco didnt want in the core (i'll get to subclasses in a second). and casey west managed to implement my session.pm replacement (and the only replacement in existence that i'm aware of) as a component without the need to reinvent session semantics. two: subclasses of session. this is where the real concern of mine comes in. While I don't find a lot of utility in wholly replacing session.pm, i can find all kinds of reasons to subclass it. POE::Exceptions subclasses both Kernel.pm and Session.pm to add exception handling to event dispatch. POE::API::Peek was originally implemented as Kernel.pm and Session.pm subclasses. Advanced profiling, based on Nick's recent patches, could be nicely and safely implemented as subclasses. Adding a new method does not break subclassing. One only needs to be aware of this method if one's subclass needs to interact with it or overload it. > You already know that, though. All I'm saying is, yea, its kinda weird > that the methods basically only effect and operate on the session...but > in some kind of fucked up way it makes sense, or maybe I'm just tired. of course it makes some fucked up kind of sense. otherwise i probably would have convinced rocco to let me get rid of it by now :) i'm just wondering if some semantic sugar isn't necessary / desired to make things easier to understand and maintain for less experienced folk. (yield suffers from further semantic problems. the wiki has notes on that.) > But dispite that, initially I agreed with you, but after having kicked > it around I kind of like the way it is...forces sanity rather than > checks for or assumes it. i'm not getting how having these methods in Kernel.pm instead of Session.pm forces sanity on the user using the modules. care to clarify? -- Matt Cashner http://eekeek.org eek at eekeek dot org
