Author Topic: Structural changes in trunk version (Read 5444 times)

Alreadythere · « **on:** March 13, 2008, 03:45:35 pm »

The following is a list of structural changes to the trunk version of BeBot, all of which will require changes in some or most 0.4 modules to work with the trunk version.

Base classes: There are added base classes for passive and active modules. A passive module is a module which doesn't react to any commands directly. Most core modules fall under this category. An active module is a module which registers commands to react directly to user input. The base class for passive modules is BasePassiveModule, which supports registering of events (e.g. cron, gmsg, privgroup, connect) as well as registering of the module with the main Bot class to enable other classes to access the functions in the module. This last function replaces any linking like the current settings module does with $bot -> settings = &$settings. BaseActiveModule is the base class for active modules. If brings default implementations of the tell(), gc() and pgmsg() functions, as well as a function to register commands and set default access rights. BaseActiveModule requires all modules to implement the central command_handler() function.
The wiki contains a more complete explanation of the base classes.
Command prefix is stripped: The central input handler in the Bot class now strips any defined command prefix out of user input while it validates the commands. The input without command prefix is then handed over to the registered module for further handling. This means that no module has to check for the command prefix anymoree, actually expecting it will break the modules. Old modules simply have to remove $this->bot->commpre out of any preg_match() call.
Changed access to core modules: Direct access of modules via $this->module->function() calls are being removed. This is replaced with a central handling and registration of such links. The Bot class brings a core($name) function to get the link of any registered module (only modules offering functions to other modules have to register in this way).
This change is currently in the work, in the end all modules will be changed to use this interface.
AOChat wrapper class: All access to functions of the AOChat class should be done over the main wrapper module AOChatWrapper (accessible via $this->bot->get_chat()). Direct access will still work, so changes to existing modules aren't exactly needed. But the wrapper functions may offer some additional checks, so it's advised to use those wrapper functions.
$commands and $cron array aren't handed over to Bot class anymore: All registering of commands and events are now done with the register_command() and register_event() functions of the base modules. For more information about using those, read the wiki about the base modules.

Alreadythere · « **Reply #1 on:** March 17, 2008, 04:52:14 pm »

Extended the wiki entry for the base classes

Blueeagle · « **Reply #2 on:** March 18, 2008, 11:21:41 am »

In my opinion we are maknig a mis-step with implementing $this -> bot -> get_XXX()->..

First off I do not see the rationale behind implementing these wrappers.

Secondly if we are to implement wrappers it would make more sense to expose them trough $this->bot->core('modulename') and/or $this->bot->module('name').
That way you could access them by ie. $this->bot->core('settings')->create(); and $this->bot->module('logon_notifies')->register();

The bot->core and bot->module variables can be set as protected and we can limit exposure to the functions that actually get the modules.

Module security should be handled on a per-module basis and not be centralized. It is my opinion that every module that does expose an interface should be availible without needing to modify the Sources/Bot.php file.

..and perhaps BasePassiveModule should be renamed BaseCore and BaseActiveModule should be re-renamed BaseModule

That way both the Base-files could implement a $register()-function but BaseCore registers to $this->bot->core and BaseModule registers to $this->bot->module.

Alreadythere · « **Reply #3 on:** March 18, 2008, 01:21:16 pm »

Quote from: Blueeagle on March 18, 2008, 11:21:41 am

First off I do not see the rationale behind implementing these wrappers.

Access to variables of objects should be through get/set functions, as you can add any needed checks or operations in a centralized way then.

Quote from: Blueeagle on March 18, 2008, 11:21:41 am

Secondly if we are to implement wrappers it would make more sense to expose them trough $this->bot->core('modulename') and/or $this->bot->module('name').
That way you could access them by ie. $this->bot->core('settings')->create(); and $this->bot->module('logon_notifies')->register();

The bot->core and bot->module variables can be set as protected and we can limit exposure to the functions that actually get the modules.

I'm using get as prefix out of habit only, the exact name isn't that important. And the get_xyz() functions for the main modules are just supposed to be shortcuts, they can be removed without any trouble (they don't offer any additional functions). But we should with functions to get the references.

I don't see much reason to use two different versions for core and module links. Most links are core links, the couple of modules that register links can easily fit into the general scheme without disadvantages.

Quote from: Blueeagle on March 18, 2008, 11:21:41 am

Module security should be handled on a per-module basis and not be centralized. It is my opinion that every module that does expose an interface should be availible without needing to modify the Sources/Bot.php file.

No module that wants to register with the Bot core has to edit the Bot.php. As said above, the specific get_settings()/whatever functions only exist as shortcuts for the main modules, there are no plans to add any more for other modules. If it's too confusing and/or we use something like core() instead of get_module() we can just as well remove them. Maybe this will remove some of the confusion around the interface.

Quote from: Blueeagle on March 18, 2008, 11:21:41 am

..and perhaps BasePassiveModule should be renamed BaseCore and BaseActiveModule should be re-renamed BaseModule

That way both the Base-files could implement a $register()-function but BaseCore registers to $this->bot->core and BaseModule registers to $this->bot->module.

See above, I don't see much reason to use two different linking sets. So there is no reason to have two different register_module() implementations.
Using BaseCore and BaseModule instead of BasePassiveModule and BaseActiveModule is a question of taste tbh. You can argue it either way (most passive modules are core modules, most active are true modules - there are a couple of exceptions to both rules though).

Blueeagle · « **Reply #4 on:** March 19, 2008, 02:54:29 am »

Ahh, my bad. I missed the module_link interface.

Alreadythere · « **Reply #5 on:** March 20, 2008, 07:06:20 pm »

Updated post: get_module() is called core() now, and get_xyz() shortcut functions got removed.

Blueeagle · « **Reply #6 on:** March 23, 2008, 04:19:57 pm »

While we're at it I've got another good(?) idea.

With the growing number of channels defining output to multiple channels has become tedious. Now some modules would most likely want to reply to more than one channel. Especially PG. That is why I think it would be "a good idea"(tm) that channels be defined as bit flags like:

Code: [Select]

define ('SAME', 1);
define ('TELL', 2);
define ('GC', 4);
define ('PG', 8);
define ('RELAY', 16);
define ('IRC', 32);
define ('ALL', 255);

That way we can do: $this->bot->ouptu($name, $msg, GC+PGMSG+RELAY); to output to GC, PGMSG and RELAY or $this->bot->output($name, $msg, ALL-TELL); to output to all public channels.

The $bot->output function would then do a series of bitwise comparissons like

Code: [Select]

if($channel & TELL)
  $this->send_tell($name, $msg);
if($channel & GC)
  $this->send_gc($msg);
...

It would be possible for modules to define a setting which directs where the reply is going.

We would ofcourse need to make a special handler for SAME (ie. remember where the command request came from). I am not sure how that would be done, but it would be possible to forward such a value to the module when the command is invoked and store it in the base module and then have the base module handle $this->output($name, $msg, $channels) and check if SAME is set and then set the appropriate channel.

Any thoughts on this approach?

Alreadythere · « **Reply #7 on:** May 01, 2008, 09:09:30 pm »

Broke backward compatibility completlely. The global $commands and $cron arrays are removed, the information is only stored inside the Bot class now. To access those arrays use the register_command(), register_event() functions of the base modules.

Khalem · « **Reply #8 on:** May 02, 2008, 11:17:53 am »

With this change done, we might want to consider doing a 0.5 development release sometime soon. Although I'm not entirely in the loop on the overall state of the tree atm.