Feature Request #4478
Changes for Kohana4
Regarding all proposed/requested changes here, you can find a working prototype here: https://github.com/srcspider/kohana4-prototype By default it's configured to sit in a kohana4-prototype folder under www. To customize see App/config/kohana4
Disclaimer: It's a prototype; it only implements enough to prove the concept and verify/test the concept. Unless it's explicitly mentioned bellow just assume anything you find missing, is missing because it's just-a-prototype. :) Also, prototype is designed for 5.3, but should be much more tidy with 5.4
- namespace support (module level) -- prototype implements an altered version of the https://github.com/srcspider/Cascading-Class-System/blob/master/CCS-Standard.md thing. It's PSR-0 compatible and modules are also inline with how PSR-0 and it's following would expect packages to look like, ie. <namespace>/<subnamespace>/<Class_Name>
- transparent/flexible execution chain -- see: Layers in prototype
- class isolation & pattern isolation -- see: Namespaces / Layers system in prototype
- common language between classes -- see: use of generic-namespace in prototype
- class, configuration and file loading outside of core -- see: CFS class
- configurable routing, and execution handling that loads things "when they're needed" (ie. no bootstrap, etc)
- more flexible and non-global exception handling -- see: Layers
- less reliance on overwrites as the one and only way to customize kohana -- see: namespaces / Layers
- self reference calls moved from Class_Name:: to static::
- central environment.php for all base configuration (directory structure etc). Also multiple environment files; skinny environment file, and default should be "best possible" (potentially multiple repositories, one for each version). -- see: environment.php for example.
- \defined('SYSPATH') => \defined('DOCROOT')
- interface for (simple) Cache and Database use; CFS should accept classes of the interface at any time -- the prototype doesn't (currently) show this... forgot =P oops
- &&/|| instead of AND/OR (because those are the correct ones)
- exception for NULL, TRUE, FALSE from constants rule; it makes sense for actual constants, but these are so common it's just a sort of forced highlighting, serves no purpose other then de-emphasize actual constants--almost all languages have them as true, false, null and everything has always worked fine
- NO class in core (in the prototype base/) may directly reference another class in core; everything is though an interface so the class can be isolated with out requiring an entire class chain to be dragged along with it
- if the class has configuration, it's in a configuration file, even if it's default configuration; there is no "hidden" configuration inside the class--ever
- all class "symbols", constants, etc are located in the interface not the class; again to avoid dragging an entire class chain along for no reason
- all interfaces should try to be as generic as possible; and methods that requires a particular class should try to pin the dependency down to a specific interface not a composite interface
- composite interfaces (interfaces extending multiple other interfaces) should only exist when there is actually a need by a method for the combination; interfaces should not be a copy of the class's implementation; there is no point to 1:1 relationships
- underscores in class names mean: "the part on the right of the underscore is a element of the group on the left" (be it because it literally extends or simply "logical extention thereof"). Examples:
- configuration, route names, etc should all have kohana in the name to avoid name collision
- default namespace for kohana would be kohana4 instead of just kohana to allow for backwards compatiblity whenever kohana5 would come about
I'm sure I forgot something... Anyway, each one of those requires a big wall of text (probably), so just let me know which you don't understand and I'll clarify.
#3 Updated by Steven G. almost 3 years ago
Jeremy Bush wrote:
There's no plans for kohana 4 right now. There's little point in even discussing it at this time.
See I told you there's a problem with your procedure.
Shadowhand/Kial: Why aren't you starting an issue on the tracker?
Isaiah: This needs to be in 4.
Zombor: You can't request for 4.
Clarification required. :P
#5 Updated by Steven G. almost 3 years ago
Jeremy Bush wrote:
I didn't close the issue. I simply said there's little point in discussing it right now.
Oh. I understand. Then I guess I posted correctly.
Just so there's no confusion, I don't expect you to go and jump on 4, I'm just posting so they're posted (as requested).
#7 Updated by Steven G. almost 3 years ago
(Don't seem to be able to edit the original issue)
Addendum -- Prototype Example.
- PHP5.4 now minimum
- interface for database and caching in CFS added
- entire prototype now works with Composer
- very simplistic event system implemented for the purpose of abstraction between layers
- task support integrated in example/prototype
#8 Updated by Steven G. almost 3 years ago
On the forum Isaiah/shadowhand mentioned how having the pseudo-"kohana4" text made it ambigous to people who didn't see it in context. I only used it since it didn't seem to be a problem for all the kohana forks everywhere to have the name in a repo linked to a personal account. :) Anyway I can see how it might be confusing since even with "prototype" in the name it's ambiguous in origin when it's the only repo with the "kohana4" in the name.
Example, and associated repo's, have been refactored to "ibidem", the command line utility also now identifies as overlord (the binary is still "minion", as in "overlord's minion").
Because of the refactoring all links have now been broken.
UPDATED LINK https://github.com/srcspider/ibidem-framework-demo
Incidentally, since this was brought up in the thread, the example is not a fork, since for one it splits the core into 3, and secondly it doesn't actually change files, per se, it replaces them, since it's an alternative way; even equivalent files in the scope of the example are not exactly serving the same purpose of the kohana version, so a rename is pretty awkward as well.
In addition the example covers roughly only the suggested changes, not a complete change, so it makes more sense to not have files it doesn't suggest alterations to. But as a fork this causes confusing, since it would imply the file is not suppose to exist, when that's not really the point.
So, basically being "fork'ed" has the only benefit of a link (and just the link itself), not worth it; potentially even confusing.