Mode Handler Plan

From the makers of InspIRCd.

And thus Brain planned a secksay mode parser

(27-18:45:43)(@Brain) om, you know when AC_GENERAL_MODE is called, yes?
(27-18:45:52)(@Brain) its not 'per mode letter' as any docs might say (wrong)
(27-18:45:58)(@Brain) its per MODE command
(27-18:45:59)(@Brain) :p
(27-18:46:15)(@Brain) with a source and target
(27-18:46:25)(@Om) craq++
(27-18:46:28)(@Om) kinda
(27-18:46:40)(@Brain) incorrectly documented
(27-18:47:10)(@Om) btw, I think OnRawMode's param should be a non-const reference
(27-18:47:20)(@Brain) you cant change them.
(27-18:47:30)(@Brain) it will screw all kinds of stuff up
(27-18:47:36)(@Brain) nothing changes them
(27-18:47:47)(@Brain) the original string is split in the same way as a strtok
(27-18:47:50)(@Brain) inserting nulls
(27-18:47:52)  -» (skenmy)(~skenmy@ChatSpike-E46B8A21807534E3.ipt.aol.com) has quit (Connection reset by peer)
(27-18:47:59)(@Brain) so changing them would confuse the hell out of it
(27-18:48:12)(@Brain) err
(27-18:48:16)(@Brain) sorry
(27-18:48:23)(@Brain) the nulls arent inserted in the mode handler
(27-18:48:27)(@Brain) theyre inserted in the command parser
(27-18:48:30)(@Brain) but you get the idea
(27-18:49:00)(@Om) Yeah, it would allow some modules people would like though. like "+b nick" working
(27-18:49:02)(@Brain) what obtuse thing are you trying to do with modes now that the rfc was never designed to allow :P
(27-18:49:27)(@Brain) imho that ban mask munging should be part of the core in 1.1
(27-18:49:43)(@Brain) its too simple to warrant writing a module for, its one function with a footprint of maybe 2k
(27-18:49:47)(@Brain) compared to a 50k module
(27-18:50:08)(@Brain) in 1.1 i want to rip out the mode handler anyway om
(27-18:50:10)(@Om) true
(27-18:50:19)(@Brain) i want to have an array modechars[64]
(27-18:50:27)(@Brain) where each is a pointer to a ModeHandler object
(27-18:50:48)(@Brain) each one handling a mode char, and the modules just instantiating and inserting one
(27-18:50:51)(@Brain) same way they do for commands
(27-18:51:03)(@Brain) would make for a damn efficient mode loop
(27-18:51:04)(@Brain) ;)
(27-18:51:07)(@Om) How would you let a module see other modes?
(27-18:51:12)(@Brain) and it would make core modes no different to module modes
(27-18:51:13)(@Om) than it's own
(27-18:51:25)(@Brain) i dont really think thats a good idea in its current form
(27-18:51:39)(@Brain) that was a kludge, because i was too lazy to do it THIS way in the first place (with mode handler classes)
(27-18:51:52)(@Om) Maybe not in it's current form. But modules should be able to see other modes, and allow/deny them
(27-18:52:05)(@Brain) as an event maybe
(27-18:52:12)(@Brain) OnPreModeLetter or such
(27-18:52:22)(@Brain) orrrr
(27-18:52:35)(@Brain) a mode HANDLER class..... of which there can only be ONE per mode letter
(27-18:52:36)(@Brain) and
(27-18:52:40)(@Brain) 0 or more mode WATCHER classes
(27-18:52:47)(@Brain) of which there can be zero or more per mode letter
(27-18:52:57)(@Brain) a mode WATCHER class doesnt implement a mode, but extends an existing mode
(27-18:53:01)(@Brain) hence, you can EXTEND +b, +o....
(27-18:53:02)(@Brain) ;)
(27-18:53:17)(@Om) I don't think it really needs more than OnPreModeLetter
(27-18:53:17)(@Brain) plus it makes it a ton faster to parse
(27-18:53:22)(@Brain) well
(27-18:53:28)(@Brain) inserting classes into sets is tons faster
(27-18:53:45)(@Brain) triggering events is slow, i want to cut down on it as much as possible in 1.1 and make it more about instantiating and inserting inherited classes
(27-18:53:52)(@Brain) same way commands sockets and timers now work
(27-18:54:18)(@Om) Hm, yeah
(27-18:54:24)(@Brain) so
(27-18:54:31)(@Brain) imagine in your mode loop:
(27-18:54:41)(@Om) Should we take it as far as being able to reload core modes?
(27-18:55:11)(@Brain) for (char* x = modes; *x; x++) {    if (has_a_mode_handler('n') { trigger_all_watchers;  if (watchers_were_happy) {  trigger_mode_handler('n') } }
(27-18:55:30)(@Brain) we can maybe fit that in someplace
(27-18:55:32)  -» (skenmy)(~skenmy@ChatSpike-E46B8A21807534E3.ipt.aol.com) has joined (#inspircd)
(27-18:55:32)  -» (ChanServ) sets (#inspircd +v skenmy)
(27-18:55:34)(@Brain) but only reload, not unload, imho
(27-18:55:39)(@Brain) too much depends on them
(27-18:55:40)(@Om) Yeah.
(27-18:56:01)(@Brain) hmmm
(27-18:56:08)(@Om) We *ought* to be able to reload some of the modules marked static really, you should be able to reload a mode
(27-18:56:09)(@Brain) i REALLY REALLY like this idea of the mode watcher and mode handler objects
(27-18:56:15)(@Brain) can someone post it somewhere, wiki this log or something
(27-18:56:22)(@Om) kk
(27-18:56:39)(@Brain) its possibly one of the best ideas for a long time :D
(27-18:56:44)(%weirdgoatguy) eccentric people running around
(27-18:56:55)(@Brain) lol