How is PSR-0 support for Kohana 3.3 going?
  • @zeebee

    'Combine regex and callback functionality in Routes'

    http://dev.kohanaframework.org/issues/4209

    OH that one. I remember it now. :)

  • A little note on this blog article from the previous page, namely: http://philsturgeon.co.uk/blog/2012/03/packages-the-way-forward-for-php#.T1XrZ9iu6YI.twitter

    Other well known developers like Ed Finkler and Chris Hartjes who record the /dev/null postcast are behind it too. Check the first episode for some of their reasoning.

    First just so everyone knows, it's actually /dev/hell podcast. (Probably renamed.)

    Secondly, allow me to transcribe some of it:

    Chris: "[...] People are going discover that once you use a framework... you become trapped by the framework. [...] It's an almost abusive relationship. And that's not the fault of the people who built them. They built them to solve their own problems. And then, they added all sorts of generic stuff to solve other people's problems. [...] Whatever the original goal was, that particular framework will always always display those characteristics."

    Chris: "[...] In the php world, and I think you're going to agree with me too Ed, the packaging ecosystem is just bullshit. [...] PEAR had the potential to be so good... and it's just it's just NOT there. And now I see this Composer-thing that the Symphony guys are pushing as an alternative to PEAR, and look at that and go Yeah this is the PEAR-thing, all-over-again"

    Ed: "[...] PHP is very good at solving a web problem from 5 to 6 years ago. And the things I want to do now... it doesn't do such a good job at. It's ability to work well, be there as a complement to rich client side applications [...] I think is problematic, and approuches in other languages are better. A ton of PHP [thinking] [...] tends to mix it's features and functionality and core fundamentals. So, PHP has set itself out to certain things very well... but those tend to be things that you'd do at around 1999 to 2005. Things like dumping html to the browser."

    If you're going to say "go check X for their reasoning" I expect positive things usually. Or at least not ass backwards to the actual claims :) unless I'm misreading and the wording is actually "pushing it [off a cliff]".

    Oh and that's the "juicy bit" of the entire 1h 20min podcast BTW. Most of the rest is just pessimism on development practices. The answer the guys on the podcast will hopefully eventually discover, is that you need to draw a line between creating a solution and searching for the ideal solution. And you need to treat that line as the river Styx.

  • How funny :)

  • This discussion is turning into a nice echo chamber. Does anyone besides @Akki have something to say, or shall we lock it up?

  • @shadowhand Personally, I think there's been quite a bit of meaningful discussion in here about PHP, frameworks in general and Kohana in particular that I've found quite eye-opening, and no Akki hasn't been the only contributor. If this isn't the type of discussion that interests you, then I guess you can do what you want - it's your forum.

  • @shadowhand

    What's your (dev team) opinion on instead of changing file names, changing class names?

    ie.

    # classes/some/example.php
    class some_example
    

    Obviously it might rub some people the wrong way, but other then eyecandy practically speaking it's better code and a more flexibile compromise. A error fix autoloader for it is trivial and can be placed in front of the PSR-0 or after it. Other libraries would have no problem with kohana's lowercase filenames since the classes would be lowercase. Any current code would be compatible and would not require changing or checking.

    If PSR-0 falls on its ass and some sane standard comes along this would also be compatible with that. :)

  • @akki, I'm not dev team but I'd say that is a much worse solution. With git being so good at tracking file renames, moving from lowercase to capitalised filenames is very easy and a very simple to understand commit. It's also very easy to reverse in future without any loss of history.

    Changing the case of classes throughout the codebase will result in an enormous commit with a huge number of pointlessly changed lines and break blame history for essentially everything.

    Also, as you've shown above, lowercasing class names is problematic in many cases like HTTP, and I think makes for much less readable code.

    I agree with the large number of PSR-0 critics about enforcing case sensitivity from a pedantic point of view, and I think it would be far better if they'd gone for an strtolower approach as Kohana does - but they haven't and given the heavy use of CamelCase in many of their projects I doubt they will.

    From a pragmatic point of view though, I really think this is not much of an issue. Recasing the files in your project isn't an enormous task (you could always write a quick script to do it, if you have hundreds of files and have stuck to one class per file). The problems you're projecting around future runtime breaks are also I think largely theoretical. It would be very easy to build a script or phing task that:

    • Gets a list of all the class files in your project
    • Runs a case-insensitive search throughout your project for any use of those class names
    • Reports any where the match is not the correct case

    If there are places where you're compositing class names at runtime I guess you'd have to pay them particular attention, but on the whole I can't see this causing much of a problem across an app's codebase.

  • We are committed to supporting PSR-0 at this point.

  • @zombor

    We are committed to supporting PSR-0 at this point.

    If the class name is lowercase, PSR-0 is fine with the lowercase filename, so it's supporting both. ;)

    @andrewc

    @akki, I'm not dev team but I'd say that is a much worse solution. With git being so good at tracking file renames, moving from lowercase to capitalised filenames is very easy and a very simple to understand commit. It's also very easy to reverse in future without any loss of history.

    I have no issue with renaming file names per se. It's the purpose behind it. [continued next quote]

    Changing the case of classes throughout the codebase will result in an enormous commit with a huge number of pointlessly changed lines and break blame history for essentially everything.

    Well I agree with your point. But I disagree with giving it priority, over the communities codebase. By changing your classes to lowercase you are fully compatible with 3.2 and earlier code. Which is an implied higher cost: kohana's code? or, the community's collective code?

    I agree with the large number of PSR-0 critics about enforcing case sensitivity from a pedantic point of view, and I think it would be far better if they'd gone for an strtolower approach as Kohana does - but they haven't and given the heavy use of CamelCase in many of their projects I doubt they will.

    Hm. I guess the problem comes down to: is case insensitive namespace/class names in PHP a feature or flaw? If it can be considered a feature then PSR-0 is a flawed implementation the correct approuch is to adapt around it. If it's a flaw then PSR-0's way is fine. What's your take?

    (Also can you explain to me why PSR-0 doesn't support numbers in namespaces?)

    Don't take this as some counter argument; just asking. I wouldn't find it so hard to accept it if it wasn't so infuriating nonsensical in so many places.


    Also, since you're here :) I got a little tangent with PSR-0/Composer's goals and our little DI talk.

    What's your opinion on: the PHP's community's allergy to interfaces?

    What I mean is, if reusing code is a problem and code becomes too tightly coupled to the framework, then isn't that exactly what interfaces are for in OOP?

    An example & Explanation

    Say you have the following class:

    class Special_Controller
    {
        public static function factory(Request $request, Response $response)
    }
    

    You are always using interfaces. Not using interfaces is actually still using an interface.

    This class's interface is: itself. It's method factory is also using the hard implementation of Request and Response as the interface.

    What this means is that if you ever wanted to use this class you will always have to have \Request and \Response. If say for the sake of argument (and clarity) the class was in namespace example\base;, that means that anyone who wants to use \example\base\Special_Controller can only use it with \example\base\Request and \example\base\Response. There's just no other way around it, the method doesn't accept anything else.

    Your options are to either replace the class with a class that you maintain yourself to be compatible to the undefined namespace (complete pain in the ass) or you abuse inheritance. When you abuse vertical inheritance you have to consider that you're still technically using the \example\base\Request for example because you're extending it. Kohana 3.2 currently abuses inheritance with it's Request extends Kohana_Request.

    Now consider the alternative...

    namespace example\abstracts;
    
    interface Request
    {
        function doStuff();
    }
    
    namespace example\base;
    
    class Special_Controller implements \example\abstracts\Controller
    {
        public static function factory(\example\abstracts\Request $request, \example\abstracts\Response $response)
    }
    

    And now you can do this:

    namespace example\base;
    
    class Request
        implements 
            \example\abstracts\Request,
            \some_framework\abstracts\Request,
            \kohana4\abstracts\Request,
            \kohana3\abstracts\Request
    {
       ...
    }
    

    (Obviously interfaces should extend there, but just for example clarity sake.)

    Where Request can be an implementation, or just an adapter of another framwork's class (it's relatively easy since you don't have to extend anything now). Being used by a framework then isn't a matter of "being built for the framework" but "supporting the framework's interface". Which means you can mix in code from different frameworks very easily.

    Isn't that the actual solution to the problem? With packages and PSR-0 you just seem to have a very fancy way of drawing in a giant pile of code. It's not making code reusable, it's giving an excuse to make code not reusable (ie. have a long dependencies tail). Or at least that's my opinion at the moment after looking more into the problem. What's your take?

  • @andrewc

    given the heavy use of CamelCase in many of their projects

    I have been thinking of this... and from that perspective it does kind of make sense; in the sense of having readable file names. Guess you convinced me Andrew. =P

    Now the question is why isn't kohana just converting it's modules to actual packages and is doing it in this kind of a package, but not really:

    eg.

    /module_name
        /app
            /views
            /config
            some_otherfile.php
        /Controller
            MyExample.php
    

    With namespace support the class there would be \module_name\Controller_MyExample obviously app would be a reserved word, but that wouldn't be a problem since it's a standard you would enforce on yourself and not one you would police on others; it also makes sense not to use it as a namespace component as it's non descriptive. You can't be the main application and yet just a component.

    Kohana modules would then be fully compliant packages; or at least I think they would.

    What's the explanation for this? Moving and Renaming are pretty much just as easy in git and almost equivalent. Same for other source control systems.

  • @Akki:

    Now the question is why isn't kohana just converting it's modules to actual packages and is doing it in this kind of a package, but not really:

    We have every intention of implementing namespaces in Kohana - in the future. Use of namespaces is completely and utterly fundamentally different to implementing PSR-0.

    Please stop suggesting namespaces as a solution to your dislike of PSR-0. Namespaces are, at a stretch, complimentary to PSR-0. They are not a replacement and are not mutually exclusive.

    If you have suggestions for our future implementation of namespace support, please file a feature request.

    If you wish to continue to discuss namespaces, please do so in another thread. This thread has already confused namespaces and PSR-0 more than I thought was possible.

  • You misunderstand. I meant it's compatible with packages, ie. it can go as a package. Not that it necesarly is one.

    Basically, instead of this:

    /module_name
        /classes
            /external_package
    

    you can just do this

    /external_package
    

    It doesn't matter if only external packages use namespaces, it's the idea that there is no difference between an external package and a module, since modules are just an extention of the package structure (more or less).

  • @akki, I'm pushed for time to reply but in short: I'd guess the vast majority of existing kohana community code is capitalised the same way as the class declarations. Partly because of IDE autocompletion, partly because its fairly natural case when using the kohana coding standards. Updating the class file name to match existing class name case is very easy, will likely require almost zero userland code changes (and can easily be scripted to check) and keeps git history clean (in both core and community code). I seriously think you're totally overblowing a non-issue.

    Personally, I think PSR-0 is flawed because of the case sensitivity (I like that php is insensitive). But I also don't like some little things about many other standards. And I also don't think Linux should be case sensitive. Point is, it is a standard and will have very little impact other than making us more compatible. Realistically, the time to disagree was either a) when PSR-0 was drafted or b) before the devs did the work to implement it.

    As to interfaces, short answer is yes I think there should be more use of them.

    And I would hate the idea of chucking all the files in a single folder with long filenames, I much prefer to have the current nested structure to keep related classes grouped.

  • @andrewc

    I seriously think you're totally overblowing a non-issue.

    I already agreed with you 2 posts ago. :)

    And I would hate the idea of chucking all the files in a single folder with long filenames, I much prefer to have the current nested structure to keep related classes grouped.

    Is that directed at something I said?

  • @akki - re PSR-0, great! :) re the last bit - sorry, I misread your latest suggestion about paths and namespaces. I much prefer having a specific classes directory under the module name, to separate the views, config etc from classes while allowing all of them to be first-class citizens of the module. Just seems more tidy to me.

  • I think the notion of supporting http://getcomposer.org/ is really interesting. Sharing modules between Frameworks is every developer's dream. Supporting PSR-0 is a step towards that.

  • @rjd22 It's not my dream, sure, it would seem to mix and match different libraries written for other frameworks or even standalone libs. too, but in reality it's a nightmare...

  • @feketegy Reusable code is a nightmare?

  • @cs278

    No, the nightmare is to use code that wasn't meant to be reused (different conventions, etc.) in a totally different environment like Symfony <-> Kohana.

    The opposite of this would be SwiftMailer, which uses the same conventions as Kohana and it works beautifully with it.

  • Symfony 2 components are reusable, the only problem is autoloading but you just need to add a PSR-0 autoloader into the stack and everything works fine. At $dayjob we've got a bunch of projects using Symfony components inside Kohana 3.0 and 3.2; one 3.0 project will even be using Composer shortly, for all the dependencies.

  • @rjd22

    I think the notion of supporting http://getcomposer.org/ is really interesting. Sharing modules between Frameworks is every developer's dream. Supporting PSR-0 is a step towards that.

    As per Kial's request I've created an issue with various suggestions for 4 and created a prototype as an example.

    In my local copy I've already converted it to work with Composer; as in the modules are loaded with composer. There were a few other things I wanted to change in the prototype, since there's a lot of back and forth code moving to repositories I'll update the prototype as soon as everything is in working order again. :)

    But anyway... that's not important. What you should know is that Composer won't just solve your dependency problems. It simply manages them. You can't just say "something/something" and expect it to go out and find it on the internet, it's still the good old configuration file where you put all your crap in; nothing more. Basically it's more or less a more transparent and universal version of git submodules from my perspective.

    @cs278

    Composer... in it's current (alpha) state is usable, but somewhat broken. The non-Pakagist way only works with the very explicit repository package declarations for example. It seems to suggest it can autodetect by itself the composer.json, but it also seems to fail to do so; I might just be missing something, but probably not considering the default example they give on my end just flat out borks a PHP error (and I've tried it on valid repositories just to be sure). Error messages are also so cryptic I initially though it was telling me my file was in the wrong encoding; instead of what was really happening which was a very simple and stupid extra colon.

    When it (eventually) works though, it's relatively elegant I suppose.

  • @Akki it's got much better, my main problem is it doesn't cache the packages.json file from packagist locally so if that goes down I'm stuck, also it's support for private GH repos is less than ideal.

  • @cs278

    You can define a fake "package" in your repository bit. :) A hassle but then you're not stuck anymore.

    Frankly I wish it's non-Packagist support was... more supported. Rather not rely on too many third party things; at least with just github I have some trust it won't just fall over (for too long). Don't trust Pakagist... and it's "submit github repo, we'll scan" seems like it might be vulnerable to some sort of identity theft--can't say for sure, since I was experimenting with Composer/Kohana didn't want to accidentally steal kohana names.

    also it's support for private GH repos is less than ideal.

    What I've been scanning it's documentation for is how to define things for autoload (like how psr-0 is currently defined) but there doesn't seem to be a way to do it... boo!

  • @feketegy Symfony 2 components are indeed trivial to integrate with Kohana, here's a module if you need one (you don't): https://github.com/zeebinz/kohana-symfony

  • @zeebee I don't need it :)

    If I want to use Symfony components then I would use Symfony itself :)

  • @feketegy Unless I'm stuck with Kohana.

  • @cs278 Then you made a bad decision, whether you patch it with other frameworks' components or not.

Howdy, Stranger!

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

In this Discussion