Basically my point was, if we can post events via the session object then in order to be consistent we should be able to do other things via the session object as well. Keeping the session aliases accessable only by POE::Kernel and letting everything else be available through the session object is inconsistent and would need to be added shortly after. Aliases were just an example of another the that the kernel does, that the session arguement should do (arguably). Also it would need to be next in order to maintain a sane and consistent API.
[..] but really, you've changed the subject. i wasn't talking about aliases. i was talking about event dispatch. we were talking about one specific piece of api that can be fixed to be much more clear. i don't really have interest in saving the world right now because i don't have time to code that big of a patch.
i think adding an event dispatch method set to the session, even if it
just called the kernel methods behind the scenes, would help clarify the
api. assuming we just add the two methods currently implemented for
event dispatch, things become pretty clear in several spots
Sticking to event routing done via the session and not providing access to other session specific methods is a great arguement for not putting event routing in the session object itself. Consistency is very important in maintaining an API that makes sense to anyone.
- Scott
