Split kohana/core into multiple modules

[lenton]

I propose kohana/core gets split up into multiple modules, here are some basic siggestions (the actual packages can be properly discussed in this issue):

• kohana/log
• kohana/config
• kohana/validation
• kohana/i18n
• kohana/session
• kohana/router
• kohana/view
• kohana/helpers

These packages will all have independent versioning of one another and begin their stable release at 1.0.0. They will be required by kohana/kohana and enabled by default in the bootstrap. They will all implement Koharness and use travis-ci so they can be tested in isolation.

Modularising Kohana will be a huge benefit as any part of Kohana can be removed and switched if it's not needed by the application. Modules can properly define what they actually depend on instead of just specifying kohana/core. After splitting up Kohana into modules we will find that we no longer need a kohana/core package.

The only backwards incompatible changes to be made by users should be to simply add these new modules to their bootstrap in place of kohana/core. Kohana will still function exactly as if they were all in the same repository.

[mintbridge]

Sounds like a good idea to me. Where do we stand on using external libraries for some of these? For example Monolog for logging, patchwork/utf8 for the UTF functions..

[lenton]

Where do we stand on using external libraries for some of these? For example Monolog for logging, patchwork/utf8 for the UTF functions..

Modularising kohana/core would definitely make switching out a kohana module with a 3rd party library a lot easier. Many applications rely on libraries such as kohana logs and kohana utf8 so I think we still should carry on developing them (even though there may be better alternatives out there).

[enov]

I feel that it's good to separate the core into smaller modules, that's probably what @shadowhand wants to have with his Ohanzee components. But maybe should we go down this road after v.3.4?

[rjd22]

I'm don't really know what version this would belong in but I think it's a great feature to have in 3.4. Splitting off most the modules should be really easy because of the CFS.

[WinterSilence]

This will require global implementation DI, it will increase the "abstraction layer" code.
How will combine these modules? New ideas is nice, but need practical solutions..

[lenton]

@WinterSilence The initial splitting of the core module would simply be a case of copy and pasting files into separate repositories, it doesn't require any changes the the code. We could start by splitting them off one by one and enabling them after the core in bootstrap.

[WinterSilence]

@lenton it's bad idea - make a step by step plan before do something. Many items only slows down the file system.

[shadowhand]

@lenton please don't copy paste, but rather split the repositories properly.

@WinterSilence said:

Many items only slows down the file system.

Nothing but FUD. Or more accurately, a sure sign of Dunning-Kruger effect.