[..]In that particular instance I was basically referring to the context switching and garbage collection checks of the session. If we're not performing the method on the session object itself, we know which session we're using. Particularly in the shorthand models (yield, invoke) as we supply the session ourself (kr_active_session) instead of figuring out if this is the active session or not, and following the proper course of events (As performed in the call() optimization I provided earlier this week). The arguements for post have not such an effect, but it does in fact operate more directly in the kernel and so far as I can tell its not really the concern.
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?
Basically, with the exception of call and post which are perminantly contextual, yield and invoke are absolutely, without a doubt going to happen in our currently active session. Control over this has been taken out of the programmers hands.
Another thing is that most everything else is done via the kernel, as well. Such as alarms, delays, selects, the fifo...moving just invocation to the session objects makes sense from an implementation stand point but I really dont see how it makes more sense for new users if they are in the session object, as I recall using POE for quite a long while before ever using a session object directly (Aside from $kernel->post($session->ID, "state") prior to discovering yield()). Aside from that I did use (and still do) mostly aliases for inter-session activites.
Now aliases belonging in the session: Thats a great arguement. I don't neccesarily think it makes sense to have the session aliases accessable only by kernel methods...but again, theres logic for that as well. And such is that we dont want a session alias set by a non-active session as its a keepalive (and logically so) for a session. This would mean a session can arbitrarily be kept alive by sloppy programming and quite frankly, setting an alias for another session really isn't something someone should be doing. Providing an interface for setting the session of a component...great...allowing one session to arbitrarily keep another session alive by setting an alias, not great.
And thats what I meant by sanity checking, in order to AVOID that behavior we have to add extra error checking on each of these session methods, cry me a river, its not a big deal. But it could result in some very miffed new users screaming "Why the hell cant you do this?". Basically, we simply have to check to ensure that whatever is being preformed is being preformed by the currently active session in order to disallow other sessions from being abusive in really unfriendly ways that aren't necessarily clear in thier unfriendliness. Instead, sure we just grab the currently active session and operate on it. But thats forcibly sane, you cannot operate on another sessions aliases...you dont have that option (Without delving deeply into shit thats very obvious you really shouldn't be delving into anyway, that is).
And thats my response to that.
- Scott
