php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #51144 spl_autoload is broken
Submitted: 2010-02-25 14:00 UTC Modified: 2015-05-12 17:07 UTC
Votes:6
Avg. Score:5.0 ± 0.0
Reproduced:5 of 5 (100.0%)
Same Version:3 (60.0%)
Same OS:1 (20.0%)
From: davi dot fol at gmail dot com Assigned: cmb (profile)
Status: Not a bug Package: SPL related
PHP Version: 5.3.1 OS: Mac OSX 10.6
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: davi dot fol at gmail dot com
New email:
PHP Version: OS:

 

 [2010-02-25 14:00 UTC] davi dot fol at gmail dot com
Description:
------------
I am aware of spl_autoload_* issues that the development team do not 
consider bugs, namely the requirement for class files to have 
lowercase names in order for spl_autoload to function. (I would like 
to think that moving forwards, we could supply a constant to 
spl_register_autoload as a best compromise BC step to change this 
behaviour to support PascalCase class names).

Anyhow, I've disabled all extensions, I believe I've exhausted all 
configuration possibilities affecting spl_autoloads behaviour, and 
it still does not work. Defining my own handler, does. It seems that 
no matter how I define the include path, spl_autoload throws 
LogicExceptions as it cannot find classes. I am hoping that its not 
the case that as Mac OSX paths contain upper case folder names, 
that the auto lowercasing behaviour of spl_autoload is affecting 
absolute paths.

As a concrete case, this IS an include path that I use- it works with 
include_once et al, supplying or omitting the trailing slash:

"/Users/davidfoley/Documents/Aptana Studio 
Workspace/www.thorium.site/Private/Library/"

The above path is a perfectly valid file path- its somewhat different 
in the sense that 'www.thorium.site' is plonked in the middle- 
thats simply the name of a virtual hosts symlinked folder. I am only 
guessing that this could be a possible reason why spl_autoload is 
not working.

Reproduce code:
---------------
Assume a class file: 
location:
www/Private/library/target.php
contents:
namespace library
{
    class target
    {

    }
}

Assume a bootloader script
location:
www/Public/boot.php
contents:
define('BREAK', '<br/>');
set_include_path('absolute/path/to/www/Private/library);
spl_autoload_extensions('.php');
spl_autoload_register();

$classFile= new SplFileObject('library/target.php', true);
echo 'The class file exists: ' . ($classFile->isFile() ? 'true' : 'false') . BREAK;

use library\target;

$instance= new target;
echo 'The class was loaded: ' . (isset($instance) ? 'true' : 'false') . BREAK;

Expected result:
----------------
The following output:

The class file exists: true
The class was loaded: true

Actual result:
--------------
LogicException 'could not load class library\target'

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-03-09 20:48 UTC] jani@php.net
-Package: Feature/Change Request +Package: SPL related
 [2010-07-11 01:51 UTC] jinmoku at hotmail dot com
see http://bugs.php.net/bug.php?id=51991
 [2012-01-22 19:38 UTC] dVaffection at gmail dot com
I use PHP version 5.3.6 on Ubuntu 11.10 and confirm this bug!
 [2015-05-12 17:07 UTC] cmb@php.net
-Status: Open +Status: Not a bug -Type: Feature/Change Request +Type: Bug -Assigned To: +Assigned To: cmb
 [2015-05-12 17:07 UTC] cmb@php.net
> could not load class library\target

The autoloader is looking for library/target.php, but obviously
this file doesn't exist. Changing the include_path appropriately
is supposed to solve the issue:

  set_include_path('absolute/path/to/www/Private');
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 21:01:36 2024 UTC