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.
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.
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.
..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).
Content
Members
Total Members: 900
Stats
Users Online
