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 and Namespaces
  • Are you planning to change the auto_loader for working with namespaces?
    Because sometimes you want to save some files inside a folder but you don't want those folders in your class name.

  • 3.3 will support autoloading from namespaces. We'll be implementing this completely:

    https://gist.github.com/1234504

  • @zombor, is there any reason for replacing "_" with DIRECTORY_SEPARATOR in the classname?
    I mean, I was expecting that with Namespaces we could choose with completely freedom our class name.
    I like how packages works in AS3, your package (namespace) reflects the folders, and your class name can be anything, is not related with the folders.

  • This is pretty much how every php framework does autoloading with namespaces. It would be inconsistent (with the standards as well as in kohana) to do it any other way.

  • That sounds like it will go perfect with our current implementation anyway :)

  • What about upper-casing file names though?

  • Yes, you are right, ZF has the same autoloader:
    http://framework.zend.com/manual/en/zend.loader.autoloader.html
    But then is impossible to have a class name (and filename) with an underscore without having a folder for that underscore.
    I think the "standard" is wrong here, this is a common "error" in Zend (included PHP), backward compatibility is braking progress.
    Kohana in general is very criticized for not supporting backwards compatibility in favor of better improvements, but I understand that in this case is very difficult to go against the current.

  • But then is impossible to have a class name (and filename) with an underscore without having a folder for that underscore.

    Of course, that's how kohana works now. That behavior is fine. It's the convention. The namespace implementation would follow our convention.

  • yes but that "convention" was only needed because PHP < 5.3 doesn't have namespaces.
    do you really see that like a good feature?
    You are not free to choose the name of you class and the structure of your folders and files.
    The only solution is to add another convention and name our classes using CamelCase. In that way you define your folders with the namespace, and you can use the name you want in your class.

  • on a side note, camel casing is not in accordance with Kohana's coding style.

  • @enridp do you have an example of when it would make sense to be able to put an underscore in your class name and not have the files in corresponding paths? The whole point is to place class files in predictable locations, not just for the autoloader but also for module CFS file structures and importantly for developers to be able to find them. I've always found the convention groups and separates class files in a very logical way.

  • @enridp Convention allows people to pull in code from many projects and use one autoloader to handle all the classes.

    I hope Kohana will be getting rid of the lower casing of file names.

  • I know that CamelCase is not the Kohana's convention, but is the only solution if you don't want another folder due to the name of your class.
    Now kohana is forcing you to names that maybe are not good for you, because a personal preference, because in your language (my language is spanish) that sounds strange, because you want to maitain some type of classes together, etc, etc, etc there are tons of examples.
    Some of them:
    I have a class Dto_Product, and a class Dto_Product_Price, and there are 2 problems with that:
    1) Because I want all my Dto in the same folder, I'm forced to start the name of my class with Dto.
    2) I can't put in the same folder Dto_Product and Dto_Product_Price.
    Those problems are very very common in Kohana.
    I want to choose where to put my class and how to name it.
    I was accepting these restrictions from Kohana, because the autoloader was much more important to me, but now, with namespaces, this makes no sense. That's why namespaces exists after all.

    Anyway, how I say, I understand that because so many libraries works in this wrong way Kohana must follow that rule too. I think the good news are that we can always change the autoloader to make it work as we expect.

    And that brings to the next question:
    Can we use the new autoloader (with namespaces) right now (I'm using KO3.1.x) ?
    I mean, do we need to change or adapt something else or just overriding the autoloader function is enough?

  • I want to choose where to put my class and how to name it.

    You can always include your files by hand and name them however you want.

    Anyway, how I say, I understand that because so many libraries works in this wrong way Kohana must follow that rule too.

    It's not wrong. It's kohana's convention. In our opinion it's correct. It's not going to change.

  • Can you argue why do you think it's correct?
    Java and AS3 doesn't work that way, and they have a huge experience in packages. This is an obvious problem of backward compatibility because PHP namespaces are only in PHP5.3+
    With namespaces you don't need to force your classname to any folder structure, the folder structure is inside the namespace.
    Why you think that is better to have:
    Model_Vendo_Product in one folder, with a lot of other Model_Vendo_ models and in one separated folder, and completely alone, Model_Vendo_Product_Category
    What is the advantage of forcing to everyone a strict relation between a class name and a folder structure?
    I have a lot of helper classes and without relation merged in the "classes" folder, just because I can't put them anywhere else without changing their names.
    If you want to put a class in a specific folder, just write the namespace for that class, that's all, I don't see any reason for changing the class name too.

  • I used to "fight" a lot of these too ... there will some things that you agree with in a framework and things you don't agree with. I have searched for a very long time before finding Kohana. I don't agree with everything (like the folder structure as you've mentioned having every DTO in one folder would be nice) but there are other better things to worry about ... all the docs, tutorials, etc. are done this way and at the end of the day, it's not worth sweating it. Like @zombor said, you can include your files by hand or figure out how to do your own auto loader and watch all the other modules that you are using not work

  • @zombor

    What's the current state of this support in 3.3

    Is it usable?

    [edit] NVM you don't even have a 3.3 in developement apparently.

  • @enridp im trying to understand you. You are using 3.1.x which in reality most of its users are still on php 5.2 aka namespaceless. Do u expect a new subversion wit namespace or what. Dont forget that its Kohana Framework not Enridp framework. My point being, the fact that u have php 5.3 doesnt mean everyone does. I mean we all knw the merits of namespacing bt that CANNOT and WILL NOT be implemented till theres a new version, maybe 3.3. I suggest u make personal changes to ur autoloader. Thats the whole point of CFS.u expect a new subversion wit namespace or what. Dont forget that its Kohana Framework not Enridp framework. My point being, the fact that u have php 5.3 doesnt mean everyone does. I mean we all knw the merits of namespacing bt that CANNOT and WILL NOT be implemented till theres a new version, maybe 3.3. I suggest u make personal changes to ur autoloader. Thats the whole point of CFS.

  • @catchphraze

    You can't inject namespaces (other then eval), so it's either "it supports namespaces" or "it doesn't support namespaces", ie. until kohana works with them, there's no real clean way to work with them yourself.

  • @catchphraze, first, DRY (just a joke ! ).
    second, I don't know why so many people feels offended when this type of debate appears, maybe it's my english (maybe my "words" are sounding offensive).
    But I'm here because I'm using Kohana, and I'm using Kohana because I like Kohana, and I ask these things because I want to learn and because I want a better Kohana too.
    And if you read my post again you will see that I was asking for "plans" in namespaces, not for changing KO3.1.
    Even more, I recalled a few times that due external libraries, global conventions, backward compatibility etc, I understand why Kohana needs to make an autoloader like that, and I agree, because we can always adapt the autoloader for our needs, or how I said, just use CamelCase in the name of our classes (this is the option adopted by ZF).
    I mean, I see it like the only solution (and the only reason) for backwards and external compatibility. But @zombor says the way this autoloader works it's correct, and I can't see any advantage of this behavior, I mean, if you want another folder you can always add it to your namespace, why mixing it with the class name too?
    I just wanted to hear the arguments for that, because that's how a forum works, and that's how I learn, that's all.

    Regards !!

  • I would also like to hear the arguments for the mapping of folders to classes.

    I am a happy kohana user and prefer the framework above all the other frameworks I have seen.

    But this bit of kohana I would like to see changed because instead of helping me it seems to be working against me. And like enridp I see in namespaces a chance to improve kohana's autoloader.

  • @enridp: You can always create your own auto loader and register that one in bootstrap.php. You could then open source it, and share it with everybody else.

    Takes less time than spending writing all these comments :-).

  • @Wouter is not about time, if you read what I said in my posts you will see that I agree with the new autoloader, even more, I'm who proposed to make your own autoloader or just use CamelCase if it doesn't fix well in your project (for example you could check if the namespace is in you /application and run your own autoloader for those classes).

    But I don't agree with the reasons, I think the only (and not minor) reason is backward and external libraries compatibility.
    But @zombor says that's not the reason, and I'm just curious to understand what are the reasons then, is not a waste of time if we can learn something @Wouter.

    Regards !!

  • @enridp I don't think you understand the implications of the autoloader. It might be JUST the autoloader for other projects but for kohana it's an integral part of how things work.

    Let's say kohana classes where namespaced to kohana and instead of class Kohana_File_Something you had namespace kohana/file; class Something .... You can't just ignore this rule in your application/ classes since now how the hell do you call them? do you call Kohana_File_Something or kohana\file\Something. The whole transparent overwrite system is broken too.

    This sort of messed up autoloader suggestion is a not a solution. IF kohana switches to a new type of autoloader, everything should adhere to that new system, for the sake of keeping our sanity; even if it means kicking backwards compatibility in the groin. :-)

  • @enridp Just because Zend uses CamelCase doesn't mean it's a standard or the best... I "REALLY" dislike CamelCase for the following reasons:

    • it's not clean, underscores feel a lot more human like
    • it's hard to control, how would you create paths with CamelCase? with underscore you just use explode('_', $var) and implode('_', $var)
    • A lot more valid reasons are here but I think those above are the most obvious
  • Given the large and potentially dangerous nature of this change for 3.3, I have started work on it now in a separate repo. The intricacies of namespaces and other PHP 5.3 features on the Kohana CFS and other features is not straight forward. I hope to push the first pass of an NS conversion to the 3.2 codebase this week. I'll link to it when it is done.

  • @rjd22 you don't need to 'create paths' with camel case. Snake case gets annoying when you have an exception called User_Access_Denied_By_Site_Policy_Exception or something like that. It's a trade off and of course not everyone likes it but that's life.

  • @rjd22 I like underscore too, but I proposed CamelCase as a solution for the className, and only because the autoloader converts underscores into folders (and with namespaces I think this isn't necessary).
    @cs278, you put a real good example of the problem existent now with underscores, your classname User_Access_Denied_By_Site_Policy_Exception is mapped to:

    user
        access
            denied
                 by
                    site
                        policy
                             exception.php  
    

    So you end with a very loooong folder structure, with a file name that probably doesn't say too much (in you ide you only see the filename in the tab title of your file, and you end up with a lot of "user" files "exception" tabs, etc.
    Another real example, I have a classname TipoDeOperacion (in english, translated word by word is TypeOfOperation), and I was forced to use CamelCase there because if not, I need 2 folders (Type folder and Of folder !).

    We can use namespaces to solve this, in your example @cs278, with an autoloader which doesn't convert underscores into folders in your classname you could have something like this:

    // file: classes\user\access\user_access_denied_by_site_policy_exception.php
    namespace \User\Access;
    
    class User_Access_Denied_By_Site_Policy_Exception
    {
    
    }
    

    even more, you can point the namespace to anywhere you want, for example User\Exceptions\ if you want to group your exceptions without changing the name of your class.

  • The fact that you don't like all the subfolders isn't a good reason to get rid of it. It's a sane convention, especially given the fact that there are TONS of other projects that use it, and it's the method given in the PSR-0 standard.

    Yeah, sometimes you'll get some long folder structures, but the rare case isn't a good enough reason to be haphazard and break an existing, good standard. We know your opinion, and you know ours. We disagree.

  • I really don't know how to make it clear. I'm not fighting ! I'm not writing this just because I have a lot of free time and I'm bored and I want to disturb some forums.
    I'm sorry If you feel that from me :(

    I will try to resume this thread:
    I said: Don't convert underscore in your class name, only use namespaces for folder structure. PROS: you can choose with freedom your class name.
    You said: No, that's not the convention, and there are a lot of projects works in the same way.
    I said: OK, backwards and external projects compatibility probably is a stronger advantage than freedom in your class name.
    You said: it's not about compatibility
    I said: OK, so I don't understand why you choose that convention then, Kohana is always trying to improve their code, why are you valorizing an old (and probably forced because the non-existence of namespaces) convention over code usability?

    And again, I'm sure you were thinking and debating this much more time than me, and you have much more experience than me, and that's why I'm asking what are your reasons, what are the PROS of your solutions and the CONS of my solution (which is not a solution at all, just a vague idea, I don't feel qualified to propose any solution at this level, but I can't see any problem with that, so I'm asking you, that's all).

  • It's mostly a coding style thing. We don't use camel case. It's MUCH more unreadable to use underscores, in our opinion. The fact that PSR-0 agrees with us is a nice coincidence. The fact you might get many levels deep of folder structure is a minor nuisance they we can tolerate. If you don't want to use underscores, and you want to use CamelCase for your classes, you can do that right now.

    Keeping everything underscore -> / keeps our conventions in line, and mixing conventions for namespaces and class names would be inconsistent.

  • @zombor, I agree with you about CamelCase, I like underscores, but I don't agree with the convention of converting underscores into folders, I don't see any reason for that.
    I proposed CamelCase just as a workaround for having a class file with a complete name and inside a custom folder.
    A better approach to me is just leave the "_" => "folder" conversion, and use only "namespace" => "folder".

    Perhaps it's extremely obvious, but I can't see the problem of not converting underscores to folders.

  • @enridp It doesn't follow PSR-0 that's the problem with it.

  • How about the following reasons:

    1. PSR-0 is a community standard so unless there is something far superior this is the path of least resistance in terms of interoperability with other frameworks/components.
    2. Using underscores is the current way for logically splitting up classes, although backwards compatibility is not a priority for Kohana development it is still a benefit.
    3. Deep folder nesting is not a "common" problem and can be resolved with CamelCase.
    4. @samsoir has explained he (and I'm sure other devs) is still investigating so none of this is final and all currently preference.
  • @DrPheltRight, following your points:
    1. OK, we can translate it as: "compatibility with external libraries/projects". I agree this is important, but I think this is not the reason why Kohana chooses PSR-0.
    2. OK. that is backwards compatibility, and maybe is important too, but the team said it's not the reason either.
    3. CamelCase is discouraged by the team.
    4. OK, that's a good notice to me, I don't feel so idiot now, maybe is not so easy as it looks...

    Another problem existing now with namespaces is that we can not rename/refactor our classes and namespaces, at least I don't know any IDE capable of this.

  • > Given the large and potentially dangerous nature of this change for 3.3, I have started work on it now in a separate repo. The intricacies of namespaces and other PHP 5.3 features on the Kohana CFS and other features is not straight forward. I hope to push the first pass of an NS conversion to the 3.2 codebase this week. I'll link to it when it is done.

    @samsoir may I have a link to the repo with the experimental version.

    Thanks in advance.
  • Akki will do - it's on my github profile, no code pushed yet
  • @samsoir I'm guessing this: https://github.com/samsoir/core since it's the only fork of the core on your profile.
  • @enridp Remember, you're free to declare your own extended auto-loading methodology either by registering a new autoloader using http://php.net/manual/en/function.spl-autoload-register.php or by extending Kohana::auto_load. Kohana is opinionated by design, but it doesn't prevent you from implementing custom autoloading behaviours.

  • Need example with NAMESPACES in application/classes.

    I have folder Port and Port/Processor.

    In Port i'm have base abstract class Processor. In Port/Processor i'm have class Booking, that should extend from Processor.

    How i'm can do it work with Namespaces? How i need name my classes?

    I'm try namespaces like Port\Processor or just Port for Processor and different names, like Processor or Port_Processor but it's not work when i'm try use it in controller.

    use Port or use Port\Processor don't work.

Howdy, Stranger!

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

In this Discussion