These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Kohana 3.3
  • I Hope Kohana 3.3 will support namespace natively :D, I've seen in the roadmap kohana3.3, have a lot feature request, and thats good,

    Kohana 3.3 will release in december 2011, is this true??

  • I believe namespacing will render the whole class naming convention useless...

  • we need backward compatibility :(

    But why?? This is a major release, in my opinion backwards compatibility is not required, furthermore it prevents doing some cool things

  • @enridp, I'm not sure how you reached that conclusion, but it's wrong. It has nothing to do with backward compatibility. If we implement namespaces in Kohana we want to make sure we Do It Right and keep core Kohana features like transparent extensions, a simplistic file system (i.e. you can always know the location of the class by the namespace/class name), and good coding standards intact. Our goal is to make 3.3 better, not just add "cool things" to it. If we can figure out a way to use namespaces to make it better I'm sure we will consider using them.

  • @Isaiah, well maybe I lose something.
    Why do you need to convert underscore into folder in the class name? can you give an example where you need it (and you can't do the same with just a namespace).

  • a simplistic file system (i.e. you can always know the location of the class by the namespace/class name)

  • Why do you need to convert underscore into folder in the class name? can you give an example where you need it (and you can't do the same with just a namespace).

    @enridp, for the last time, we will be implementing the PSR-0 PHP Working Group Standard for Namespaces and autoloading of classes. What part of that do you not understand?!?!

  • we will be implementing the PSR-0 PHP Working Group Standard for Namespaces and autoloading of classes

    @Sam: without any changes? I like Kohana's downcased file names, because it's easier to find the file with a class (i.e. no difference between new Controller_AJAX or new Controller_Ajax for example).

    a simplistic file system (i.e. you can always know the location of the class by the namespace/class name)

    class Controller extends Kohana_Controller and class Controller extends Kohana\Controller is basically the same thing

  • @samsoir: without any changes? I like Kohana's downcased file names, because it's easier to find the file with a class (i.e. no difference between new Controller_AJAX or new Controller_Ajax for example).

    I'm currently working to the standard, period. We'll have to decide if we implement the standard in full or part once this has been done.

    class Controller extends Kohana_Controller and class Controller extends Kohana\Controller is basically the same thing

    True, in fact thus far it has been a case of renaming the classes to use NS rather than underscore and updating class references in the code. This is of course only the first pass. More work to be done.

    So now as it stands;

     class Controller extends \Kohana\Controller {}
    

    But this is not necessarily going to be the final implementation. As all of this has major impact on how the CFS and transparent extension works. For example, within the Kohana_HTML class, we can now do this;

    // Old method
    $some_const_value = HTML::SOME_HTML_CONST;
    
    // PHP 5.3 loveliness
    $some_const_value = static::SOME_HTML_CONST;
    
  • Sure, late static binding is a great thig, but sometimes classes use another classes (ORM uses DB for example). Do you know some way of doing it more flexible? Something like

    if (class_exists('\DB'))
    {
        \DB::query(...);
    }
    else
    {
        \Kohana\DB::query(...);
    }
    

    (This is bad example of course)

  • In this case, at the moment the fully qualified namespace for the class transparent extension is used, \DB and \ORM in your case.

  • I mean situations when, for example, someone may already have a class named DB. It would be great if we could tell Kohana's core classes to use another class instead of DB (KoDB, for example)

    class KoDB extends \Kohana\DB {}
    

    and then ORM's internal methods would use KoDB::query(..) etc

  • These are some of the issues that will get ironed out over time, and is why I've started this now. In the first pass I'm just converting to FQN format using the PSR-0 standard. The following passes will refine and provide detail about how Kohana wants to handle this.

  • @samsoir I understand how the new autoloader works, but I don't agree how it works !
    Maybe with an example I can explain it better:
    This is how it works now:

        \namespace\package\Class_Name => /path/to/project/lib/vendor/namespace/package/Class/Name.php
        \namespace\package_name\Class_Name => /path/to/project/lib/vendor/namespace/package_name/Class/Name.php
    

    This is my proposal:

        \namespace\package\Class_Name => /path/to/project/lib/vendor/namespace/package/class_name.php
        \namespace\package_name\Class_Name => /path/to/project/lib/vendor/namespace/package_name/class_name.php
    

    And I was asking why the last version is not viable with Kohana, or why do you think is better the first version? maybe you can show PROS and CONS.

  • Can you imagine if your project had 50 classes, and they were all in the same directory?

  • @enridp Just use CamelCase naming for your classes. If you have many classes that have long names perhaps you are approaching the naming of your classes from the wrong direction?

    What actual problems have you had whereby you have classes hidden in deep directories?

  • @zombor, there's nothing (from my viewpoint, maybe I'm losing something) you can do with the current autoloader (undersocres are converted to folders in class names) that you can't do with only namespaces.
    If you have 50 classes, you can create different namespaces and hence have those classes in different folders.
    Maybe you can put an example of something that you can do with the current autoloader and can't be done without it.

    @DrPheltRight, you can read some common problems here:
    http://forum.kohanaframework.org/discussion/comment/65797

  • You've not outlined any actual problems over there. You just said it yourself:

    there's nothing you can do with the current autoloader (undersocres are converted to folders in class names) that you can't do with only namespaces.
    

    That goes the other way around too. In the end it's just preference and there is no right or wrong. And when there is no right or wrong, you might as well go with the standard.

  • @DrPheltRight, no it doesn't goes the other way. I can create a class called "My_Class" inside this file: /any/folder/my_class.php. You can't do that witht the current autoloader (you can't use underscores without adding a new folder).

  • Yes but an equivalent solution would be to use CamelCase. We do not currently use CamelCase but introducing psr-0 would make that a lot easier. For example classes and folders would be named in CamelCase too. Like so: classes/Controller/Blog/Post.php. I personally like this style but I currently adhere to Kohana's lowercase file naming conventions because that's how Kohana currently rolls.

  • is not better to abandon "underscore => folder" conversion instead of mixing CamelCase with underscore convention?
    I see these advantages of using only namespaces for defining the folder structure and leaving the class name = file name:
    1. You can put your class inside any folder you want, it doesn't depends on the name of your class.
    2. Your filename is always equals to your classname, so you dont have files like "post.php" which in reallity represents the class "Controller_Blog_Post".

    If there aren't any CONS with this approach, why not using it?

  • @enridp There are cons, it doesn't adhere to PSR-0!

  • Enough already! @enridp we hear you, but we're not going to adopt your policy for the reasons stated hitherto an exhaustive amount of times. Let's just leave it alone shall we?

  • Well, first of all I can't find any issues in redmine about introducing namespaces in 3.3, so I don't really know how do you want to do that. But in the recent month I worked heavily on refactoring my own framework to use namespaces (it's originally based on Kohana 3.0 but it's current code is pretty far from it..), so let me give the kohana core devs some suggestions based on my current experience:

    1) all kohana classes should be under Kohana's own namespace, furthermore all official modules should have their own namespace under the kohana namespace. The modules should have at most 1 class out of their namespaces, and it should be under the kohana namespace. This exception can be useful for classes that contain only or mainly static factory methods - in these cases not putting them into the module namespace makes the coding easier. Examples: \kohana\Text , \kohana\database\query\SelectQuery , \kohana\DB The own namespaces will definitely put an overhead on the code and they will decrease code readability, but this is a must-have for a modern framework to do it this way, and to avoid classname collisions for sure. It would be really nice if the framework woud ensure that no users will meet situations like this: http://forum.kohanaframework.org/discussion/comment/64249

    2) My problem with PSR-0 is that the name of the class can not be determined based on it's file path. For example if you have path/to/lib/my/own/Class.php then the name of the class in it can be my\Own\Class or my\Own_Class . This can cause some serious headaches for people who want to write code generators or whatever other development tool. Therefore I would recommend not fully implementing PSR-0, or if you do so, then it must be a coding standard to not to have _ characters in classnames. If it is followed by kohana core framework developers, module authors and users then no problem.

    3) If you use namespaces, then it's a good practice to have classnames that are versbose on their own too, not only with their fully qualified name. For example if you have now a class names DB_Query_Select then in the namespaced version it's good to name is db\query\SelectQuery. It will result in more readable code imo. It can have some further good side effects, let me explain it: many kohana users met the problem they have classes with the same suffixes, and you may also have a view with the same name. So if you have Controller_User, Model_User, and a view named user.php then you have 3 open user.php files and I don't know any PHP IDE-s that can help you to differentiate them. In such cases it would be a great help if the class names would be \app\controller\UserController and \app\model\UserModel.

    4) if you follow the above convetion, then i would strongly recommend to camelcase your file names (btw it's also needed by PSR-0).

    that's my 2 cent

  • @samsoir, how you can see I'm not the only with problems understanding that convention, and even ZF has problems with it (that's why they are using CamelCase) if you stated an exhaustive list of reasons for your adoption, I think I didn't read or noted it, can you resume it or link it again?
    These are the reasons that I can remember:

    1. Kohana convention is to convert "_" into folders (but that convention is not needed anymore with namespaces, why to maintain something that only add pain and restrictions?)
    2. PSR-0 works in the same way. @zombor said this is just a coincidence, Kohana is not restricted by that.
    3. Backwards compatibility. @Isaiah said it's not about backwards compatibility either.

    So I'm insistent because you never tell us (or I didn't notice it) why you choose that, what are the pros over the other option which seems less restrictive and logic.

    And I don't understand your "fury", what's the sense of having an open source project if you don't like to share or debate the ideas behind it?
    Is not easier just to put your list of pros for using PSR-0 and your list of cons for not using PSR-0 without the "_" conversion?

  • Enough already! @enridp we hear you, but we're not going to adopt your policy for the reasons stated hitherto an exhaustive amount of times. Let's just leave it alone shall we?

    I haven't seen any well substantiated reasons. enridp has done a much better job making his case. Could someone address each of his points please? Crystal also warns that with PSR-0 and underscores, a class can not be determined based on it's file path. That's a big mistake.

  • I haven't seen any well substantiated reasons

    http://forum.kohanaframework.org/discussion/9740/kohana-and-namespaces

    Additionally, there is an issue in our development environment where this discussion should be happening.

  • @enridp Zend have always used camel case for class names, that pre-dates PSR-0 and PHP 5.3. For example Zend_Session_SaveHandler_DbTable.

  • @samsoir, that's my post and there aren't any reasons there marking problems with deleting the "underscore to folder" conversion.
    In the issue request is not any discussion either.

    I see only 2 reasons for underscore conversion, backwards compatibility and standard convention.
    But the standards works fine in other libraries like ZF because they are working with CamelCase !
    So they are using underscores because they want a new directory, they are not forced to make a new folder.
    In kohana we "can't" use CamelCase so your are restricting the name of our files and where they are without any benefit (or if there's some benefit it must be some type of top secret because you don't want to list them, and that would be enough for making a lot of people really happy).

    PROS of not converting underscores:
    1. filename = classname
    2. you put the filename/class anywhere you want (you define it with the namespace)
    3. you can name your class with completely freedom and control
    4. the autoloader is faster

    Can you make a list of CONS ?
    or a list of PROS for PSR-0 ?

    I think backwards and external library compatibility is important (you said that's not a reason, I don't understand that too). But I think is possible to maintain both solutions:
    1) Try to find the file without converting _
    2) If doesn't exist any file, try to find the file after converting the _

    We can use && instead of AND and everything is OK anywhere, but we can't choose to use underscores without creating new folders so this is not about convention @samsoir, and this is not a trivial decision, you should at least argue your solution.

    And please don't convert this into a fight, it's a forum, about an open source project that all we are using, we are not here for destroying any community, you don't need to defend from me, I'm just asking for two lines of arguments, much more less than the lines written at the moment, and I'm not the only interested.

    Kohana doesn't have the biggest community, and is always criticized by its documentation, anyway I chose it from a lot of another options, and by one reason, I read the code and I liked the ideas, the code is well explained, we can see many times comments that explains why you are making that. That's important to me, to understand why I'm making the things in that way, I don't like to use blackboxes and accept dogmas, I always try to make a pause for reading the code and understand it. I did the same with many libraries and frameworks like jQuery and Flex.

  • In kohana we "can't" use CamelCase

    Why can't you? You can name your classes how you want. We do it frequently at sittercity when we don't want a class a million subdirectories deep. Here's an example: Model_User_MembershipType

    We want all our model_user_* models under the same directory, so we make that one word.

    1. you put the filename/class anywhere you want

    No, you can't put the file anywhere you want. You HAVE to have a convention for autoloading files. Either you always convert classes to underscores, or you never do. Our convention is converting underscores, because that's the way we like it. There's no technical reason to do it either way.

    1. the autoloader is faster

    It's so trivially small, it's not worth discussing.

    Can you make a list of CONS ?

    The biggest con is that all your classes are in the SAME folder. That can get unwieldy (in my opinion) when you have lots of classes.

    We've got hundreds of classes in our application.

  • Why can't you? You can name your classes how you want. We do it frequently at sittercity when we don't want a class a million subdirectories deep. Here's an example: Model_User_MembershipType

    OK, I put "can't" (quoted) because I now we can, I didn't know you were using it at really because is not the Kohana convention and also when I porposed it as a workaround (not solution) for forcing the files inside a folder, I get punished by many members, even you @zombor :(
    http://forum.kohanaframework.org/discussion/comment/65814#Comment_65814

    No, you can't put the file anywhere you want. You HAVE to have a convention for autoloading files

    yes, of course, but you can choose where to put the file independently of the name of your class. The namespace is the only thing defining your folder structure, not your class name. Therefore, you can put the file anywhere you want, just define the correct namespace for that, in code:

    // file:  classes/this/is/my/custom/folder/structure/my_class_name_ca_be_anything_now_thanks_god.php
    namespace this\is\my\custom\folder\structure;    
    class My_Class_Name_Can_Be_Anything_Now_Thanks_God
    {
    }
    // file with PSR-0: 
    classes/this/is/my/custom/folder/structure/my/class/name/can/be/anything/now/thanks/god.php
    

    The biggest con is that all your classes are in the SAME folder.

    why? you can define a new folder defining a new namespace.
    Maybe ou can put an example of something that you can't do without converting _ to folders.

  • In the end, this is all preference. There's no point in debating it, really. Tabs vs spaces, BSD vs allman style, emacs vs vim, etc. We aren't going to convince each other either way.

  • Windows versus Linux. Chrome versus Firefox. iOS versus Android. :)

  • enridp: there's a simple solution as suggested earlier - write your own autoloader and do whatever you want with your classes. If that's not good enough for you, I guess you need to switch frameworks :)

  • @dfox that was my solution at really :)
    also the idea of using CamelCase as a simple workaround :P
    I was asking for the reasons for that decision, the advantages of choosing that and the cons of not.
    But how I said, this is not about preferences or conventions, because I can use Kohana with Netbeans or Eclipse and it works OK, I can use && or ANDand it works OK, I mean I can choose that and everything is OK.
    But we can't choose the name of your class and the folder for it with PSR-0, that's a terrible decision and error to me, obviously I won't use it, but I was hoping you have a real reason for making that strange decision (and learn something from that of course).
    @zombor you could avoid mixing CamelCase with underscore style in your sites just choosing the right autoloader, I'm really surprised for your decision.

    I repeat, I was only interested in knowing the reasons, for learning something, and to be sure that I was not losing something important (because I don't want to use PSR-0).
    If you can't find any problem with not using underscore conversion, and your decision is just because PSR-0 is nice for you, then that's a reason too, and it's OK to me, I don't want to make a fight from this, if you think PSR-0 is OK for Kohana, you are the team, and I don't agree but I accept it.

  • The reason the PSR-0 standard uses underscores as a directory separator is for backwards compatibility and to allow logical grouping where a namespace is undesirable. I don't see why Kohana's autoloader can't search for `Project1\Models\User_Type` in `Project1/Models/User/Type.php` and following that `Project1/Models/User_Type.php`. You aren't fixed with Kohana's default autoloader implementation anyway as they're easily stacked/replaced.
  • @enridp the fact that CamelCasing isn't "Kohana convention" or coding style doesnt mean you cant do it. IMHO, as long as it wont be a bottleneck, ISDGAF.
  • Getting back to the actual topic here... (why the hell does everyone care so much for this underscore business?)

    My take, from experimenting with them, namespaces are utterly stupid and unnecessary for the kohana environment. And that standard there is nothing more then 3 steps backwards if it's implemented to the point where kohana actually abandons the current way of doing things just to be example of how doing it only using that standard would work. Actually it's ten times worse, just take a look at how code in fuel works.

    Namespace work on the principle of isolation, while kohana works on the principle of "everything is put together, but only the highest level implementation is used" which totally bumps heads with isolation. Because you can't have names be symbolic like you have now and at the same time universally fixed/unambigous.

    Simple example...


    <?php<br />
    namespace test;

    class HTML extends \kohana\HTML
    {
    public function test() { echo "test\HTML"; }
    }

    namespace kohana;

    class HTML
    {
    public function test() { echo "kohana\HTML"; }
    }

    class Test
    {
    public function run() { HTML::test(); }
    }

    namespace test;

    \kohana\Test::run();


    Output `kohana\HTML` and there's no way around it. PHP namespaces are compile time, they are literally just a fancy way of adding a string at the front of all your classes. So if you want the current magic you have to either not use namespaces or use only one namespace!

    Also, I might add, fully implementing namespaces into the kohana process doesn't benefit interoperability at all! Kohana has no problem with other kohana stuff, in fact is has excellent handling, and for everything else all you need is ONE namespaces not support for every project to have their own personalized (completely and utterly useless otherwise) namespace that just makes life for everyone else harder.
  • @Akki the `use` construct and `class_alias()` might be handy.
  • > My take, from experimenting with them, namespaces are utterly stupid and unnecessary for the kohana environment.

    This is my conclusion as well.

    > kohana process doesn't benefit interoperability at all!

    It *does* have one benefit. Actual class conflicts, like DB, Log and Config, which are all pear classes. I'm not sure the trouble of implementing them is worth it though.
  • @cs278

    It's explicit, not magic. Literally it's no different then just calling the fully qualified name, it's just a convenient shortcut; if you're lazy.

    Also it would have to go in the kohana namespace. How exactly are the kohana devs to go about doing that... ;)

    The other alternative just results in a convoluted mess. And it's a viral convoluted mess since module creators would have to follow the same insane standard. I'm actually not even sure it would reliably work (lol).

    @zombor
    > It *does* have one benefit. Actual class conflicts, like DB, Log and Config, which are all pear classes. I'm not sure the trouble of implementing them is worth it though.

    I though I explained this already months ago there's no "conflict problem" it's all because by default kohana comes with faulty loading. You are loading stuff, before you even specify the loading location, hence your problem. The only reason nothing breaks at the moment is because you've hotwired APPPATH and SYSPATH in there.

    Anyway, I think it's plenty worth it for kohana to have namespaces to the point where it isolates kohana things from the rest of the universe. Everything else (autoloading, directory structure, etc) however... NO.

  • BTW, @zombor do you have a link to that secret Namepspace repo samsoir was talking about in the other thread?
  • > I though I explained this already months ago there's no "conflict problem" it's all because by default kohana comes with faulty loading.

    Of course there's a "conflict". You can't possibly use both the kohana Log class and the pear Log class in the same application. It doesn't matter how much we change our loader or anything like that. You can't use both.

    I'm not saying this is good enough of a reason to bother with namespaces, but that fact is still there.
  • Not to be picky but you really wouldn't want to use 'Models' as a package name - unless you're writing a program about vital-statistics that is :)
  • @zombor

    Oh THAT class conflict.
  • Why PHP namespaces? They are ugly as sin. :-/ I cry everytime I look at them. (And before you respond to the Why? I know why. I just hate the syntax.)
  • > It *does* have one benefit. Actual class conflicts, like DB, Log and Config, which are all pear classes.
    Does anyone care about Pear classes?
  • @themusicman

    Apparently yes. Though that wasn't the point there.

    The point is by having Kohana in a namespace you get interoperability with ANY non-kohana stuff that has a naming conflict otherwise—which isn't in a namespace itself. And I say that because the naming problem happens only when BOTH don't have a namespace.
  • @themusicman, I hate the syntax too, and because I think that every decision must have a reason (and this is causing me a lot of problems when I ask for those reasons :P ) you can read about the "reasons" for the ugly syntax here:
    https://wiki.php.net/rfc/namespaceseparator
  • @Akki I understand the benefits of namespaces. I use them in Ruby and JS all the time.

    @enridp I had not seen that before, but it confirms something for me. That it was a result of terrible decision making. +1 for using a decision matrix and -100 for thinking that because you can fill it with some numbers means you made the right decision.

Howdy, Stranger!

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

In this Discussion