Ohh... okay, sorry, I'm dumb. Never mind.
Yeah, I did change my mind at some point and forgot to update the example.
My original thought was to let the code handle "everything" (like setting up of hooks), though at some point I realized that the core features code was not really designed to work the way I wanted, so instead of overhauling that code (or at least make some important changes) I decided it was easier to just let the coder deal with the way they wanted to integrate into Elk (in other words DIY).
Though, I added a "shortcut":
Hooks->get()->enableIntegration('Test_Integrate'); and the specular disableIntegration.
Using this method you can tell ElkArte to load a class at run-time and "register" live the hooks without having to pass through the database.
So, a better example would be:
<?php
class Test_Integrate
{
public static function register()
{
// $hook, $function, $file
return array(
array(
'integrate_something',
'Test_Integrate::a_function_to_call',
)
);
}
public static function setting_callback($value)
{
if (empty($value))
Hooks::get()->disableIntegration('Test_Integrate');
else
Hooks::get()->enableIntegration('Test_Integrate');
}
public static function a_function_to_call()
{
// Do something
}
}
This should let Elk call Test_Integrate::register "live", that will register hooks on-the-fly.
I know, this can be somehow slower than using the database (you have some more function calls), though it's much easier for people not used to code, for example if we want to give someone a snippet of code, now we have to package it because otherwise hooks will not be inserted into the database and the code will not run, this way, instead, hooks can be added and modified without having to install-uninstall-reinstall, etc. Just replace the file and the code will work. 
Of course, an addon can use the "normal" way to load hooks, that's just "yet another way".
I hoe something of what I wrote makes sense... 
emanuele runs
Modern, Free, Powerful