Yes, it is possible to register hooks that way, and your insight that the registrations execute before the Initialize function is correct, and is central to Lua. When (any) Lua interpreter reads code, it first parses it into an internal representation, and then executes *all* of it. It doesn't mean it calls all functions, but rather, the execution sees "function Initialize() ... end" and knows "aha, this code creates a new function and names it Initialize", so it internally registers a new function of the name and points it to the block of executable code. Then it sees some function calls to AddHook, so it does those immediately.
There might be some negative points to registering hooks this way. I'll describe how Cuberite loads plugins, and you'll see them.
First Cuberite makes a list of all .lua files in the plugin folder, and it sorts the list by name [*]. Then, it loads each file (load = reading and executing the code, as described above). Then it asks Lua to execute the global function Initialize. So what could go wrong? As long as your plugin is within just 1 file, not much, really. But consider this:
File a.lua:
File b.lua:
In this case, the plugin is loaded, file-by-file, so first the file a.lua is loaded and executed first. The hook registration fails, because OnPlayerMoving is unknown at this point (thus nil, by Lua definition). If the file names were swapped, then everything would work just fine, which is quite unfortunate, because it hides the possible problem until someone refactors the code and renames the files again. For this reason, we do encourage people to use the Initialize function as the place where all initialization should be done - when Cuberite calls that function, you can be sure that whatever the file load order, your global symbols are already defined correctly.
[*]: Special exception: the Info.lua file is always loaded as the last one, so that the function references inside it work properly.
There might be some negative points to registering hooks this way. I'll describe how Cuberite loads plugins, and you'll see them.
First Cuberite makes a list of all .lua files in the plugin folder, and it sorts the list by name [*]. Then, it loads each file (load = reading and executing the code, as described above). Then it asks Lua to execute the global function Initialize. So what could go wrong? As long as your plugin is within just 1 file, not much, really. But consider this:
File a.lua:
-- At global scope, outside all functions: cPluginManager.AddHook(cPluginManager.HOOK_PLAYER_MOVING, OnPlayerMoving)
File b.lua:
function OnPlayerMoving(...) -- The actual implementation end
In this case, the plugin is loaded, file-by-file, so first the file a.lua is loaded and executed first. The hook registration fails, because OnPlayerMoving is unknown at this point (thus nil, by Lua definition). If the file names were swapped, then everything would work just fine, which is quite unfortunate, because it hides the possible problem until someone refactors the code and renames the files again. For this reason, we do encourage people to use the Initialize function as the place where all initialization should be done - when Cuberite calls that function, you can be sure that whatever the file load order, your global symbols are already defined correctly.
[*]: Special exception: the Info.lua file is always loaded as the last one, so that the function references inside it work properly.