TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Kohana 3.4: codenamed "bridge"
  • Hey all!

    This was written around 3 weeks ago, I am sorry if there is any outdated info

    Lately (read last few months) there was too much discussions in the forums and IRC about the future of Kohana.

    We are pretty much stuck because the core devs are too busy, and/or do not believe in the framework anymore and/or do not believe in the framework based software development in general. Here, I have to give my special thanks to @Zeelot3k, who took time to respond to all issues on Github and Redmine concerning the release of Kohana 3.2.

    What remains for us, the community, is either to fork the project or to wait more. I am definitely still wanting to wait more, as I do not have the resources to fork. However, in my understanding, waiting is also should be a proactive.

    This is why I have compiled here my toughs regarding my vision of what can be the next Kohana.

    Kohana, a blurry roadmap?

    I can clearly see that Kohana has a good roadmap. It's not that we don't know what we should do next. In fact, we have a clear goal towards the 3.4 release. It's right there, on Redmine. What makes it blurt is Kohana's environment:

    • We're pretty much isolated. PHP/FIG/Composer community has its own roadmap. We're unsure if we should follow them or not.
    • Core developers do not believe in CFS anymore. They prefer IoC/DI design. Personally, I don't mind to better redesign the core, but I also prefer keep the CFS.
    • Core developers, rightfully, teach us clean coding, coding without a framework, and use the framework only as a delivery mechanism.
    • Core developers do not have time to code for the framework.

    Kohana 3.4, the bridge

    Addressing the situation described above, steps for the next version(s) of Kohana:

    Release 3.3.2

    Releasing 3.3.2 still requires lots of efforts, because some of the bugs we closed in 3.2.3 also applies to 3.3.2. However, we do not support PHP 5.2 for 3.3.x series. Which means that we have to rewrite some of the PRs with language construct that were not available in PHP 5.2, for performance. Also, a rewrite is a must for some other PRs that have classes re-factored in version 3.3.

    Another issue is to support PHP 5.6, which will probably be generally available in the next few months. Fortunately, they did not deprecate a lot of stuff. Again, fortunately, Travis-CI provides the PHP 5.6 runtime, so it would not be too hard to test for.

    A debatable issue would be to support HHVM, which have come a great way towards full Zend engine compatibility. Of course, they still need few months, or years, for 100% compatibility, but I presume Kohana should run fine on HHVM. Travis-CI provides the HHVM runtime.

    Release 3.4 with full namespace and full PSR-0 and PSR-4 support

    What I am suggesting here is to keep the current API of Kohana 3.3.x series. Which means we probably only need to namespace and rename our classes according to the PSR-0 standard. A PSR-4 support would also be helpful for shorter directory structures which might be good for the CFS transparent inheritance. PSR-4 basically allows us to treat the underscore character just like any other character, so we do not have to divide the path into other folders. It probably allows us to do things like this:

    // path: classes/Kohana/Kohana_Exception.php
    class Kohana\Kohana_Exception { ... }
    
    // path: classes/Kohana/Exception.php
    class Kohana\Exception extends Kohana\Kohana_Exception { }
    
    // path classes/Kohana/Core/HTTP/Kohana_Header.php
    class Kohana\Core\HTTP\Kohana_Header extends \ArrayObject { ... }
    
    // path classes/Kohana/Core/HTTP/Header.php
    class Kohana\Core\HTTP\Header extends Kohana_Header { }
    
    Release a compatibility layer/module with Kohana 3.3

    Instead of refactoring our big apps to support Kohana 3.4, a compatibility module will help us use Kohana 3.4 and to slowly change our code with regards to PSR-0/PSR-4 and namespacing. I am talking about a module that will init the 3.3 autoloader and will have the old classes extending the core 3.4 classes. I don't think we need to init the autoloader in case we decide not to support PSR-4 in Kohana 3.4. This helps large codebases to slowly refactor its classes, while the old classname conventions can live with the new one.

    Release 3.5 with the feature requests of 3.4

    Unfortunately this means that we have to reschedule all the features of Kohana 3.4 to Kohana 3.5. Personally, I give those features a priority over PSR-0/PSR-4/Composer stuff... But we're in emergency "mode" now...

    Kohana, the bridge, and YOU

    Yeah, it seems it's all about us. Why us and why it's called the bridge? Because:

    • This roadmap is a bridge towards the rest of PHP community. We will be closer to other PHP developers with our code.

    • It is a safety bridge, in case of Kohana dies. Our re-factored code might live in other frameworks, with default PSR autoloaders.

    • It is a bridge towards a brighter future of Kohana. Kohana will use namespaces and will catch other frameworks at least with regards to namespacing.

    Happy Coding!

  • "I can clearly see that Kohana has a good roadmap. It's not that we don't know what we should do next. In fact, we have a clear goal towards the 3.4 release."

    this is not the right way. In the beginning we need add and implement new mechanisms\interfaces. follow the path of gradual upgrade does not make sense.

    Later I will write a more detailed action plan.

  • Thanks for the update on the Kohana 3.4.

    Regarding HHVM everyone eyes on it. I sure kohana runs fine on HHVM. We're running our [GleezCMS] (https://github.com/gleez/cms). We're pretty much confident, it works 99%. We faced minor issues on HHVM.

    We're running a demo here as well http://hhvm.gle.gs/

    It's a nightly custom build of HHVM for Centos 6.5 which can be [found here] (http://yum.gleez.com/6/x86_64/repoview/hhvm.html)

  • this is not an update on Kohana 3.4, but a suggestion.

  • System requirements


    • PHP

      php.net: Please note that the PHP 5.3 series will enter an end of life cycle and receive only critical fixes as of March 2013. All users of PHP are encouraged to upgrade to PHP 5.4.
      New minimum version 5.4.

      Pros:
      • Support for traits - flexible groups of methods
      • Short array syntax: $a = [4, 5];
      • Always available short_open_tag <?=, it's convenient to use in view
      • Class member access on instantiation: (new Foo)->bar();
      • Safe mode is no longer supported, magic quotes has been removed
      Cons:
      • Call-time pass-by-reference was removed, so using it will raise a fatal error.
        function foo(&$var) {
            $var++;
        }
        
        $a = 1;
        foo($a);
        echo $a; // 2
        

    • PHP extensions

      Added optional supporting Hash


    PSR standards


    • Coding style

      I like the old style, but PSR popular - most PHP programmers write in a similar style. On this basis, the style will change according to the standards PSR-0, PSR-1, PSR-4. PSR-2 is not adopted - saved most of the old features.

      Additional changes:
      • Array Brackets: use a short syntax ['a' => 'b', 'c' => 'd']
      • Arrays as Function Arguments: Alternative for wrapping long lines
        // Incorrect
        do($bar, 'this is a very long line',
            array(...));
        
        // Correct
        do(
            $bar, 
            'this is a very long line',
            array(...)
        );
        
      • Indentation:
        $text = 'this is a long text block that is wrapped. Normally, we aim for '
            . 'wrapping at 80 chars. Vertical alignment is very important for '
            . 'code readability. Remember that all indentation is done with tabs,'
            . 'but vertical alignment should be completed with spaces, after '
            . 'indenting with tabs.';
        
      • String Concatenation:
        // Correct
        $str = 'one' . $var . 'two';
        // Incorrect
        $str = 'one'.$var.'two';
        
      • Switch Structures: The block (including break) inside a case or default must be indented by 1 tab. Don't add break at end.
        switch ($var)
        {
            case 'bar':
            case 'foo':
                echo 'hello';
                break;
            case 1:
                echo 'one';
                break;
            default:
                echo 'bye';
                // break;
        }
        
    • Interfaces

      Added interfaces and abstract classes described in the PSR-0, PSR-3, PSR-4 (autoloading classes, logging).


    Pros:

    • Simpler for third-party programmer
    • Easier to integrate with third-party libraries, will not be mixing coding styles

    Cons:

    • Take time to get used to the innovations
    • Requires updating the code and documentation


    Architecture classes


    • Differentiation of classes on static and dynamic

      Dynamic classes should not contain static methods and properties. "Factory" and "singletons" should be made ​​in separate classes.
      class StaticClass
      {
          protected static $a = 0;
      
          public static function getA()
          {
              return static::$a;
          }
      
          public static function setA($value)
          {
              static::$a = (int) $value;
          }
      }
      
      class DynamicClass
      {
          protected $a = 0;
      
          public function getA()
          {
              return $this->a;
          }
      
          public function setA($value)
          {
              $this->a = (int) $value;
              return $this;
          }
      }
      
      For methods of dynamic classes returns void recommended (whenever it's possible) replace void to $this. This allows to call methods "chainable": (new Foo)->setA()->setB();
    • Preference to protected\private properties

      Public property is not declared unless absolutely necessary. Access to the properties must be accessed through special methods - setter\getter, combined methods (get+set) not used. Methods should check\typed values ​​used public properties. Public methods should check\typify obtained values ​​of the arguments (except typed arguments). Private properties\methods changed\called only into protected methods.
      class Foo
      {
          // @var string
          protected $str = '';
      
          // @var array
          protected $arr_prop = array();
      
          // Method - getter $str
          public function getStr()
          {
              return $this->str;
          }
      
          // Method - setter $str
          public function setStr($value)
          {
              // Typing argument value
              $this->str = (string) $value;
          }
      
          // Method - setter $arr_prop
          public function setArrProp(array $value)
          {
              $this->arr_prop = $value;
              // "Chainable" method
              return $this;
          }
      }
      
    • Initializing static classes

      Static classes inherit abstract class that contain method initialize() (or init()?), uses for initialize properties. At autoloading verified whether the class inherits the interface and if it's true, run initialization method.
      abstract class Statical
      {
          protected static function initialize()
          {
          }
      }
      
      class Foo extends Statical
      {
          protected static $is_windows;
      
          protected static initialize()
          {
              self::$is_windows = DIRECTORY_SEPARATOR != '/';
          }
      
          public static getIsWindows()
          {
              return self::$is_windows;
          }
      }
      
    • Blocking dynamically create properties

      Dynamic classes inherit abstract class that contain methods __get() and __set().
      // Incorrect:
      class Foo
      {
          public $a = 'It`s good';
      }
      
      $foo = new Foo;
      $foo->b = 'It`s bad'; // Set new property
      echo $foo->b;         // Get new property
      
      // Correct:
      abstract class Dinamical
      {
          public function __get($name)
          {
          }
      
          public function __set($name, $value)
          {
          }
      }
      
      class Foo extends Dinamical
      {
          public $a = 'It`s good';
      }
      
      $foo = new Foo;
      $foo->b = 'It`s bad'; // throw exception!
      


    Interfaces\abstract classes


    @todo interface for data - container. Eg. configs.

    @todo interface for collector and adapters (implements data interface). Eg. collector: Cache, adapters: CacheFile, CacheApc.

    @todo rename Сore as App, using only as container for general setting (environment, caching, profiling). Move constants from index.php into App as properties. Also coder can override class for adding "helper" methods (set\get meta tags, plug assets files (сss, js)).

    @todo regroup classes, eg. Security::check()\Security::token() into separate class CSRF, Security::strip_image_tags() into HTML, Kohana::sanitize into Security, etc.

    @todo abstract model (implements data interface) with validation\filter (move from current ORM model).

    @todo Move collector Cache and adapter CacheFile from cache module into system.

    It's only 1/3 of what I wanted to write, continuation added later. Was somewhat "blurry", gradually add details ^_^

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion