KohanaPHP » Kohana v3.x

You can add more than one autoloader. ;)

Chris Smith wrote:

You can add more than one autoloader. ;)

Chris, thank you, I know that. But it worth nothing to add namespace support the core

Thank you :)

Dmitry T. wrote:

Something like this: http://groups.google.com/group/php-standards/web/psr-0-final-proposal?pli=1

I think we already implement everything there except namespaces. Since 3.3 will require 5.3, we can include namespace autoloading as well.

This issue does not cover the debate over kohana using namespaces in it's core, however.

I've had nothing better to do so been refactoring Kohana to namespace and pushing the namespace version in various projects of various complexity to check for interference. Meaning, checking if namespaces don't just screw something up really bad (like the fancy controller/model loading, you know the whole string concatanation trick =P). Here's a working copy of the core: https://github.com/srcspider/core/tree/3.3/feature/minimal-Namespace-support (this is very minimal interference implementation BTW; ie. everything will just work like you're used to only it will be namespaced) Currently everything's looking good.

About this PSR-0 thing https://gist.github.com/1234504 (I'm guessing this is what you meant) it can't be properly supported IMO, since in theory it goes against the "Kohana way". That proposal is for a flat system not a hierarchical system like kohana. So a true implementation isn't possible, other then what Cris proposed of having it as a backup autoloaded after the Kohana one.

A hybrid alternative would be to ignore the hierarchy as conflicting with the requirement so you just implement it at a class level, but that would screw with backwards compatibility of modules a lot; because "classes" would have to be changed to "kohana" — some cases like how loading vendor extentions would need to change as well; well the recommendation at least (not that the old way wouldn't work anymore). Well, not that backward compatibility isn't being screwed with anyway, but as long as you're using a module that doesn't have dependencies into "new namespaced classes" it would work; you just call it from the global namespace, ie. add a \ in front of the usual name. I don't use that many modules so dunno how extensive or damaging this change would be.

I'll see about getting an experimental version of proper autoloading later (currently it's merely "ignore namespaces") and test how it behaves and looks in various contexts; right after I refactor database and cache to get more complex project examples up and running for testing (been running some hacked togheter versions of those and they seem to require some more precise refactoring to get working properly; damn Spl classes and other nonsense, hehe).

Currently my impression is, it's a pain. If you don't have unittests setup it's going to be even more of a pain! But... it's not that hard and technically with a full conversion it should make no difference. Oh and there's the annoying little things like getting used to using \strlen instead of strlen (not that writing strlen doesn't work).

As long as the user doesn't have too many PHP-specific classes (Exception, Spl*, Reflection*, etc to name just the usual), the conversion is also more or less just one find & replace of defined('SYSPATH') or die with namespace kohana; \defined('SYSPATH') or die along with a copy paste of <?php namespace kohana; ?> in view files that contain PHP in them.

Here's another place with PSR-0, in case more links break: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

Might be related? https://github.com/kohana/core/pull/185

Okay - So we have an issue with PSR-0 support.

with "Controller_Welcome" in "classes/Controller/Welcome.php" our route needs to be this:

Route::set('default', '(<controller>(/<action>(/<id>)))')
    ->defaults(array(
        'controller' => 'Welcome',
        'action'     => 'index',
    ));

notice the capital W?

The knock on effect of this is "site.com/Welcome" vs "site.com/welcome". The latter does not work.

I vote for all-lowercase file names like it always was in Kohana. This is easier and no need to remember where is a capital letter and where not

@Dmitry T: All lowercase means not supporting PSR-0.

We have chosen to support PSR-0 along with nearly every other major PHP project out there. So, lowercase file names are not an option.

How would controller classes look like?
Controller_News
Controller_news
Controller_Admin_News
Controller_admin_news
?

Dmitry T. wrote:

How would controller classes look like?
Controller_News
Controller_news
Controller_Admin_News
Controller_admin_news
?

Controller_News
Controller_Admin_News

Good to hear. Thanks

Kiall Mac Innes wrote:

@Dmitry T: All lowercase means not supporting PSR-0.

We have chosen to support PSR-0 along with nearly every other major PHP project out there. So, lowercase file names are not an option.

I'm not sure lowercase file names are needed, however we are "breaking" php by making class names case sensitive. PHP sees Foo, fOO and foo as all the same thing and PSR-0 would load them as different things. Following a strict coding standard would help with this, but it would be almost impossible to find mistakes where class names were typed wrong. For example let's assume your file was named 'Foo.php', and you've loaded the 'Foo' class in your code. If later in your code you called new foo; it would work correctly and you would never notice anything was wrong with your code.

I realize there isn't much we can do if we want to support strict PSR-0 compatibility.

Isaiah DeRose-Wilson wrote:

Following a strict coding standard would help with this, but it would be almost impossible to find mistakes where class names were typed wrong.

The fatal error someone would get with a line number would not be enough to debug the problem? I consider this a non-problem. Kohana is for smart people.

Jeremy Bush wrote:

Isaiah DeRose-Wilson wrote:

Following a strict coding standard would help with this, but it would be almost impossible to find mistakes where class names were typed wrong.

The fatal error someone would get with a line number would not be enough to debug the problem? I consider this a non-problem. Kohana is for smart people.

You wouldn't get a fatal error if the class was already loaded. If php had case sensitive class names and threw a fatal error this would be a non-issue. The only issue is we are making php class names case sensitive some of the time (i.e. the first time you use a class the name is case sensitive). My only issue is consistency and changing default php behavior.

Related: http://dev.kohanaframework.org/issues/4504