Author Topic: Core Modules Depending on Other Core modules (Read 2471 times)

Glarawyn · « **on:** June 13, 2007, 05:51:30 pm »

I've run into this a few times now, so perhaps we should do a check on core module interdependency. If a core module depends on another core module, we need to make sure that dependencies are satisfied before loading other modules. We are using require_once, so we don't have to worry about calling require_once("../core/Security.php") multiple times, so loading modules before the foreach loop that loads alll modules won't hurt.

So far I've hit these dependencies:
Many core modules depend on Security.php
Many core modules depend on Settings.php
BotHelp.php depends on AccessControl.php*

Ohter core modules could depend on AccessControl.php as well, but BotHelp.php is the one that generated an error for me.

Glarawyn · « **Reply #1 on:** June 13, 2007, 06:36:13 pm »

AccessControl.php, FlexibleSecurity.php, OnlineDB.php, PlayerNotes.php, StringFilter.php, User.php depend on Settings.php.

BotHelp.php depends on AccessControl.php.

I think that's it.

Ebag333 · « **Reply #2 on:** June 13, 2007, 06:53:42 pm »

It seems that there's a situation where many modules can rely on many modules (and do), but you never really know what requires what.

In my (feeble) mind there are a few options.

1) Hard code it so we load them in the order in which we need.

2) Somehow make loading functions dynamic so that when we load the module, and that function doesn't exist, we don't get an error (not sure if this is possible).

3) Specify what the modules require in each module that has dependancies, and then dynamically load them in order that we need. (Possible to get loops of dependancies this way...)

4) Change it so that we load essentially all modules at once (well, once for core once for modules, once for custom, etc), maybe via include, or something similar, or perhaps one is built on runtime...hmm...then you could easily enable/disable modules via settings inside the bot rather than having to manually enable/disable them. You could even have it actually start using the module dynamically rather than requiring a reboot (I would see 3 options, On, Off, and Disabled. On means just that, Off means it's loaded but not actually used, Disabled means we completely ignore it and in order to enable it you have to turn it to on/off then restart the bot).

Dunno if any of these are useful at all or not. Just throwing out suggestions.

Glarawyn · « **Reply #3 on:** June 13, 2007, 07:58:02 pm »

If a module calls $this -> bot -> something -> function() in it's constructor, and something is not aoc or db, then that module is depending on something being loaded. The Bot, aoc, and db classes are needed to start the bot so they are already loaded when modules load.

I dug through all the core modules and found only Settings and AccessControl being called from core module constructors, so I think hard coding the Security, Settings, and AccessControl modules to load before the other core modules works fine.

pusikas · « **Reply #4 on:** June 14, 2007, 08:23:44 pm »

I know I have posted about this somewhere already... why not just put a "require" with all the core modules a module needs into it? That sounds a bit confusing... what I mean is, that if a core module needs Security to run, just put a require_once("security.php") into it. If Security has already been loaded, nothing happens. If not, it is loaded now. Then the load order of the modules no longer matters, or rather, it sorts out itself.

Ebag333 · « **Reply #5 on:** June 14, 2007, 09:41:51 pm »

Quote from: Glarawyn on June 13, 2007, 07:58:02 pm

I dug through all the core modules and found only Settings and AccessControl being called from core module constructors, so I think hard coding the Security, Settings, and AccessControl modules to load before the other core modules works fine.

At what point do we move modules out of Core and into Sources?

Seems that Settings and AccessControl are becoming more than just "core" modules and actually moving into the realm of being required to even run the bot. (Obviously they're not quite there yet, just seems they're headed in that direction.)

Khalem · « **Reply #6 on:** June 15, 2007, 02:42:22 am »

Agreed. Settings and AccessControl are pretty much an integral part of the bot now, and cannot really be removed without breaking just about everything.