Feature Request #4001

Fully Support PSR-0 autoloading requirements

Added by Dmitry T. over 3 years ago. Updated over 2 years ago.

Status:ClosedStart date:05/17/2011
Priority:HighDue date:
Assignee:Jeremy Bush% Done:

80%

Category:Core
Target version:v3.3.0
Resolution:fixed Points:

Description

Something like this: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

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.


Related issues

Related to Kohana v3.x - Bug Report #4443: 3.3.0 Core Class Capitlization Change Breaks install.php Closed 02/13/2012
Precedes Kohana v3.x - Bug Report #4441: Clean up use of CameCase in class names. Feedback 02/12/2012

Associated revisions

Revision 67939be9
Added by Kiall Mac Innes almost 3 years ago

Initial pass for PSR-0 autoloading support. Refs #4001

Revision 7a12b2ba
Added by Kiall Mac Innes almost 3 years ago

Initial pass for PSR-0 autoloading support. Refs #4001

Revision 38061c9d
Added by Kiall Mac Innes almost 3 years ago

Initial pass for PSR-0 autoloading support. Refs #4001

Revision 82952bec
Added by Kiall Mac Innes almost 3 years ago

Initial pass for PSR-0 autoloading support. Refs #4001

Revision 93480c14
Added by Kiall Mac Innes almost 3 years ago

Initial pass for PSR-0 autoloading support. Refs #4001

Revision e387def1
Added by Kohana Jenkins almost 3 years ago

Initial pass for PSR-0 autoloading support. Refs #4001

Revision 139177b2
Added by Kiall Mac Innes almost 3 years ago

Temporarily enable the pre PSR-0 compatiblity autoloader. Refs #4001

Revision a725a68e
Added by Kiall Mac Innes almost 3 years ago

Initial pass for PSR-0 autoloading support. Refs #4001

Revision d46853b4
Added by Kiall Mac Innes almost 3 years ago

Initial pass for PSR-0 autoloading support. Refs #4001

Revision 29e93494
Added by Kiall Mac Innes almost 3 years ago

Initial pass for PSR-0 autoloading support. Refs #4001

Revision cb64b293
Added by Kiall Mac Innes almost 3 years ago

Initial pass for PSR-0 autoloading support. Refs #4001

Revision f0bc8896
Added by Kiall Mac Innes almost 3 years ago

Initial pass for PSR-0 autoloading support. Refs #4001

Revision 8221614b
Added by Kiall Mac Innes almost 3 years ago

Initial pass for PSR-0 autoloading support. Refs #4001

Revision 4e667099
Added by Kiall Mac Innes almost 3 years ago

Initial pass for PSR-0 autoloading support. Refs #4001

Revision 91ca2bf2
Added by Kiall Mac Innes almost 3 years ago

Initial pass for PSR-0 autoloading support. Refs #4001

Revision cef1d230
Added by Kiall Mac Innes almost 3 years ago

Missed a file on the first pass for PSR-0 autoloading support. Refs #4001

Revision 8243d50c
Added by Kiall Mac Innes almost 3 years ago

Disable the pre PSR-0 compatiblity autoloader now that all core modules have been updated for PSR-0. Refs #4001

Revision 4eb61803
Added by Kiall Mac Innes almost 3 years ago

Refs #4001 - ucfirst() the controller name for PSR-0

Revision 83d0f215
Added by Kiall Mac Innes almost 3 years ago

Refs #4001 - ucfirst() the controller name, if it was matched from the URL, for PSR-0

Revision 0aaf50cc
Added by Kiall Mac Innes almost 3 years ago

Update MemcacheTag filename for PSR-0. Refs #4001.

Revision e44612df
Added by Kiall Mac Innes almost 3 years ago

Fixup Route tests after PSR-0 changes. Refs #4001.

Revision c5c45ac6
Added by Kiall Mac Innes almost 3 years ago

Switch to ucwords() for controller and directory route matches. Refs #4001.

Revision 5b8db1e1
Added by Woody Gilk almost 3 years ago

Clean up c5c45ac6a8b09ee5925c6f94df521f66dc84c0d8 and use empty() instead of array_key_exists() to prevent modifying empty strings, refs #4001

Revision d457c06c
Added by Chris Bandy almost 3 years ago

Class names are case-sensitive. Refs #4001

Also clean up the method description.

Revision 8e250936
Added by Kiall Mac Innes almost 3 years ago

Update database config for PSR-0. Refs #4001.

Revision 7956a216
Added by Paul Dixon over 2 years ago

adding an explanation of PSR-0 support of file naming conventions, Refs #4001

Revision 31bfd8b1
Added by Lorenzo Pisani about 2 years ago

move PSR-0nification of parameters to below the defaults loop
refs #4001
included more unittests

History

#1 Updated by Jeremy Bush over 3 years ago

  • Status changed from New to Closed
  • Resolution set to wontfix

We don't support namespaces or require any php5.3 features right now.

#2 Updated by Dmitry T. over 3 years ago

  • Status changed from Closed to Feedback

Why not just add it as an option? It does not mean that Kohana REQUIRE php5.3, it just means it supports it without breaking anything

#3 Updated by Chris Smith over 3 years ago

You can add more than one autoloader. ;)

#4 Updated by Dmitry T. over 3 years ago

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

#5 Updated by Jeremy Bush over 3 years ago

  • Target version set to v3.3.0
  • Resolution deleted (wontfix)

Targeting this for 3.3, since we'll officially support 5.3 features then. This issue will make sure this happens.

#6 Updated by Dmitry T. over 3 years ago

Thank you :)

#7 Updated by Jeremy Bush over 3 years ago

  • Category set to Core
  • Status changed from Feedback to Assigned
  • Assignee set to Jeremy Bush
  • Priority changed from Normal to High

#8 Updated by Jeremy Bush over 3 years ago

  • Subject changed from Add support autoloading for namespaced classes to Fully Support PSR-0 autoloading requirements

#9 Updated by Steven G. about 3 years ago

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.

#10 Updated by Chris Bandy about 3 years ago

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

#11 Updated by Jeremy Bush almost 3 years ago

  • Target version changed from v3.3.0 to Unscheduled

#12 Updated by Jeremy Bush almost 3 years ago

  • Target version changed from Unscheduled to v3.3.0

#14 Updated by Kiall Mac Innes almost 3 years ago

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.

#15 Updated by Dmitry T. almost 3 years ago

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

#16 Updated by Kiall Mac Innes almost 3 years ago

  • % Done changed from 0 to 80

#17 Updated by Kiall Mac Innes almost 3 years ago

@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.

#18 Updated by Kiall Mac Innes almost 3 years ago

  • Description updated (diff)

#19 Updated by Dmitry T. almost 3 years ago

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

#20 Updated by Jeremy Bush almost 3 years ago

Dmitry T. wrote:

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

Controller_News
Controller_Admin_News

#21 Updated by Dmitry T. almost 3 years ago

Good to hear. Thanks

#22 Updated by Isaiah DeRose-Wilson almost 3 years ago

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.

#23 Updated by Jeremy Bush almost 3 years ago

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.

#24 Updated by Isaiah DeRose-Wilson almost 3 years ago

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.

#26 Updated by Jeremy Bush over 2 years ago

  • Status changed from Assigned to Closed
  • Resolution set to fixed

Also available in: Atom PDF