Deprecate module initialisation

[lenton]

Now that transparent extension is to be deprecated, the module initialisation feature is the only thing holding our modules back from being standard composer packages. The use of init.php unnecessarily couples packages to the Kohana framework making them unusable without this cascading filesystem package.

In Kohana 4.0 there would be no such concept as a 'module' any more, only normal composer packages which are optionally registered in the CFS!

Replacement

Initialisation needed for a class to function correctly should take place in its own constructor. Any other exceptional initialisation (such as needing to be run before any classes have been instantiated) has to be done by the user as part of the installation process of that package.

Targeted Version

Deprecation: 0.1 (Kohana 3.4)
Removal: 1.0 (Kohana 4.0)

Implementation

The ModulesInitializer class and interface will be marked as deprecated.

[enov]

@lenton module concept is needed, because Kohana is a framework. A module, as opposed to a standard package, contains resources structured in a framework specific way besides the source code. Yes, modules are tied to the framework. Resources can be views, assets, configs, i18n, messages, and a guide folder, among other things.

In symfony, bundles are registered with the kernel using a special class that extends Bundle. They are initialized with boot() and deinitialized with shutdown(). If we want to remove init.php, I think we should provide an alternative, as module initializations are handy and are done once, and helps users easily add modules. For example, we can call the init() method of a special class, that by convention, is the name of the module. We can use the key of the modules array for the class name, instantiate it and call its init(), for example:

$cfs = new CascadingFilesystem($cache, [
    'Vendor\Module\One' => 'directory/path/one',
    'Vendor\Module\Two' => 'directory/path/two',
    'Vendor\Module\Three' => 'directory/path/three',
]);

Then, I might roughly have:

class One extends Module
{
    public function init()
    {
        // do module initialization here
    }
}

[lenton]

@enov Init files are a bad design pattern imo. You can't inject objects into the init script which means everything has to be global. What happens when we want to use a custom Route class for example. This problem is solved when you can inject objects into a class's construct or method and the initialisation takes place there. This is why we had those confusing problems of needing to set Kohana::$log, Kohana::$config, etc. before initialising the modules. If a class needs an object, it should always be injected.

module concept is needed

We can still call them modules, what I meant to say was that they'd have no precursors different to that of a normal composer package.

[enov]

Yes, I agree with you regarding init.php files. But I was arguing if we should provide an alternative method to initialize a module.

[lenton]

@enov I don't think there's any better alternative than moving the initialisation code to the suitable classes. I think a special initialisation standard would just hide architectural problems.

For example, the codebench module currently defines one route in its init.php. This could be moved to the codebench class construct and users would be required to instantiate it in their bootstraps.

$codebench = new Codebench();

You may argue that having it work out of the box without having to instantiate a class in your bootstrap is better but when we convert over to dependency injection, we have to do this anyway.