|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #61422 Lack of autoload on type hinting breaks class_alias
Submitted: 2012-03-16 21:06 UTC Modified: 2012-05-01 13:51 UTC
Avg. Score:3.8 ± 0.8
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:2 (66.7%)
From: danko at very dot lv Assigned:
Status: Open Package: SPL related
PHP Version: 5.4.0 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
30 + 29 = ?
Subscribe to this entry?

 [2012-03-16 21:06 UTC] danko at very dot lv
I found #39003 which implies that autoload *was* called for type hinting previously and called for removal of this "unnecessary" feature.

I beg to differ. Our framework depends on using class_alias to provide a dynamic modular structure, and one real class may have multiple aliases depending on situation, and these aliases are currently added when needed. Therefore, if an object is creating using alias X (or no alias at all) and is passed to a function expecting the same class under alias Y (and no object was created using that alias) a completely invalid fatal error is raised (see a simplified demo below).

I would also like to point out, that if after calling autoload it turns out that it was not, in fact, an alias, the call will fatally fail anyway, so a really useless autoload will be only called once. I don't see any "resource consumption" problem here.

Test script:

	class Demo { }
	// An "autoload" handler creating an alias for the same class
	spl_autoload_register(function ($class) {
		class_alias('Demo', $class);
	// Create a Demo object using "A"
	// and pass that to function expecting "A"
	function success(A $test) {
		echo "Success ".get_class($test)."\n";
	success(new A());
	// Create a Demo object using "B",
	// then create another Demo object using "C"
	// and pass that to function expecting "B"
	function also(B $test) {
		echo "Success ".get_class($test)."\n";
	new B();
	also(new C());
	// Create a Demo object using "X",
	// and pass that to function expecting "B"
	function fail(X $test) {
		echo "Success ".get_class($test)."\n";
	fail(new Y());
	// Note that all of these names refer to the same class,
	// and all objects are of the same class

Expected result:
Success Demo
Success Demo
Success Demo

Actual result:
Success Demo
Success Demo
PHP Catchable fatal error:  Argument 1 passed to fail() must be an instance of X, instance of Demo given


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2012-03-16 21:10 UTC] danko at very dot lv
Sorry, what I meant in the last example is
	// Create a Demo object using "Y",
	// and pass that to function expecting "X"
 [2012-05-01 13:51 UTC] danko at very dot lv
-Type: Bug +Type: Documentation Problem
 [2012-05-01 13:51 UTC] danko at very dot lv
It hit me that:

- The behaviour is consistent with instanceof

- Calling autoload in instanceof is unacceptable (for obvious reasons), no bug here.

- The case with instanceof is much worse, since instead of raising an error instanceof returns a WRONG RESULT and it is the CORRECT BEHAVIOUR.

- This is hardly obvious and is bound to lead to some beautiful glitches.

I therefore propose that a warning is placed on the page for __autoload / spl_autoload_register and/or class_alias (if it is, indeed, the only thing this problem would break).
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sun Jun 20 12:01:23 2021 UTC