# __autoload() enhancement

- Thread: https://externals.io/message/15739
- Original archive: https://news-web.php.net/php.internals/15739
- Started by Zeev Suraski on 2005-04-03T10:05:22+00:00
- Messages: 28
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/15739.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #15739 — Zeev Suraski — 2005-04-03T10:05:22+00:00

URL: https://externals.io/message/15739#15739

All,

One problem that became apparent after the introduction of __autoload(), is 
that different pieces of code, sometimes coming from different sources, may 
want to declare this function in a different way.  Today, __autoload() is 
treated like any other function, so it's impossible to re-declare it.

Marcus tried to solve it by introducing an __autoload() wrapper in 
SPL.  Personally I think it's probably not the right way to go, but that's 
beside the point right now.

What I'd like to suggest is a change in the behavior of __autoload(), so 
that multiple __autoload()'s could be defined.  Essentially, declaring 
__autoload() would in fact add the function to the list of functions that 
are called in case a missing class is referenced.  However, it will not 
actually place a function named __autoload() in the PHP function 
table.  That way, it would be possible to declare multiple __autoloads(), 
and have all of them called when a missing class is spotted.

The two issues with this solution are:

1.  It will be impossible to use the standard means to determine whether 
__autoload() is declared or not.  I don't think that's a very important 
issue but it's there nonetheless.
2.  We need to determine what makes sense as far as calling order if we 
have more than one __autoload().  My guess would be calling them in the 
order they were registered, and checking whether the class was defined 
after each one (if it was - stop).

That solution maintains downwards compatibility (almost, other than issue #1).

Thoughts?

Zeev

---

## #15742 — Zeev Suraski — 2005-04-03T10:53:38+00:00

URL: https://externals.io/message/15739#15742 · In reply to: #15739

At 14:21 03/04/2005, Andrey Hristov wrote:
>Zeev Suraski wrote:
> > […]
>  Hi Zeev,
>if there will be chained __autoload() functions, isn´t it a good idea
>to give to the user the possibility to register autoload funcs like it is
>with the shutdown functions. I think that the user creating the queue is more
>reliable than relying on the include file order except if all the __autoload()
>appear in one file in the sequence they are going to be used. Therefore every
>submodule of a system can register it´s own __autoload() which will know how
>to handle the module classes. The handling can be different for another 
>module.

Why should the order of the queue matter?  Regardless of which solution we 
pick, it will be pretty hellish if the system behaves differently based on 
the order of autoload()'s.  The benefit of using __autoload() is that it's 
downwards compatible.

Zeev

---

## #15746 — Zeev Suraski — 2005-04-03T11:22:58+00:00

URL: https://externals.io/message/15739#15746 · In reply to: #15739

At 15:18 03/04/2005, Andrey Hristov wrote:
>  Hi Zeev,
>the idea one __autoload() may not be capable of loading therefore the next
>one in the chain should be executed to try to load/define the needed code.
>bool(false) returned from __autoload() means try with the next in the chain,
>bool(true) everything went fine skip the rest of the queue.

What I had in mind (primarily to maintain downwards compatibility), is that 
the engine will check whether the class exists after each call to an 
autload() callback.  If it exists - control returns to the script.  If it 
doesn't - the next autoload() is called.  That way we don't need to rely on 
return values.

Either way, though, the order shouldn't matter...

Zeev

---

## #15745 — Andrey Hristov — 2005-04-03T12:18:29+00:00

URL: https://externals.io/message/15739#15745 · In reply to: #15739

Zeev Suraski wrote:
> All,
> 
> One problem that became apparent after the introduction of __autoload(), 
> is that different pieces of code, sometimes coming from different 
> sources, may want to declare this function in a different way.  Today, 
> __autoload() is treated like any other function, so it's impossible to 
> re-declare it.
> 
> Marcus tried to solve it by introducing an __autoload() wrapper in SPL.  
> Personally I think it's probably not the right way to go, but that's 
> beside the point right now.
> 
> What I'd like to suggest is a change in the behavior of __autoload(), so 
> that multiple __autoload()'s could be defined.  Essentially, declaring 
> __autoload() would in fact add the function to the list of functions 
> that are called in case a missing class is referenced.  However, it will 
> not actually place a function named __autoload() in the PHP function 
> table.  That way, it would be possible to declare multiple 
> __autoloads(), and have all of them called when a missing class is spotted.
> 
> The two issues with this solution are:
> 
> 1.  It will be impossible to use the standard means to determine whether 
> __autoload() is declared or not.  I don't think that's a very important 
> issue but it's there nonetheless.
> 2.  We need to determine what makes sense as far as calling order if we 
> have more than one __autoload().  My guess would be calling them in the 
> order they were registered, and checking whether the class was defined 
> after each one (if it was - stop).
> 
> That solution maintains downwards compatibility (almost, other than 
> issue #1).
> 
> Thoughts?
> 
> Zeev
> 
  Hi Zeev,
the idea one __autoload() may not be capable of loading therefore the next
one in the chain should be executed to try to load/define the needed code.
bool(false) returned from __autoload() means try with the next in the chain,
bool(true) everything went fine skip the rest of the queue.

Andrey

---

## #15751 — Alan Knowles — 2005-04-03T12:58:36+00:00

URL: https://externals.io/message/15739#15751 · In reply to: #15739

I dont know if you read the blog comments here:
http://www.akbkhome.com/blog.php/View/79/require_once+is+part+of+your
+documentation..html
and here
http://www.akbkhome.com/blog.php/View/77/is+__autoload+evil%3F.html

and slightly related
http://www.akbkhome.com/blog.php/View/76/require_once%2C+one
+optimization+too+many%3F.html

It's pretty clear that people want to use autoload to save them having
to deal with include paths.. (and perhaps save a few stat calls) - the
more straightforward solution would be to add a include/require callback
handler - so that rather than a class instantation action, magically
doing file operations, you had a simpler and more obvious way to manage
inclusions.

But I guess Until I bother hacking something up for it, it'll remain
little more than another heckle from the audience. ;)

Regards
Alan


> All,
> 
> One problem that became apparent after the introduction of __autoload(), is 
> that different pieces of code, sometimes coming from different sources, may 
> want to declare this function in a different way.  Today, __autoload() is 
> treated like any other function, so it's impossible to re-declare it.
> 
> Marcus tried to solve it by introducing an __autoload() wrapper in 
> SPL.  Personally I think it's probably not the right way to go, but that's 
> beside the point right now.
> 
> What I'd like to suggest is a change in the behavior of __autoload(), so 
> that multiple __autoload()'s could be defined.  Essentially, declaring 
> __autoload() would in fact add the function to the list of functions that 
> are called in case a missing class is referenced.  However, it will not 
> actually place a function named __autoload() in the PHP function 
> table.  That way, it would be possible to declare multiple __autoloads(), 
> and have all of them called when a missing class is spotted.
> 
> The two issues with this solution are:
> 
> 1.  It will be impossible to use the standard means to determine whether 
> __autoload() is declared or not.  I don't think that's a very important 
> issue but it's there nonetheless.
> 2.  We need to determine what makes sense as far as calling order if we 
> have more than one __autoload().  My guess would be calling them in the 
> order they were registered, and checking whether the class was defined 
> after each one (if it was - stop).
> 
> That solution maintains downwards compatibility (almost, other than issue #1).
> 
> Thoughts?
> 
> Zeev

---

## #15757 — Jeff Moore — 2005-04-03T14:24:20+00:00

URL: https://externals.io/message/15739#15757 · In reply to: #15739

> What I'd like to suggest is a change in the behavior of __autoload(), 
> so that multiple __autoload()'s could be defined.  Essentially, 
> declaring __autoload() would in fact add the function to the list of 
> functions that are called in case a missing class is referenced.  
> However, it will not actually place a function named __autoload() in 
> the PHP function table.  That way, it would be possible to declare 
> multiple __autoloads(), and have all of them called when a missing 
> class is spotted.

Coupled with namespaces, declaring multiple __autoload functions seems 
natural:

namespace x {
	function __autoload() {
	}
	...
}

namespace y {
	function __autoload() {
	}
	...
}

Absent namespaces, the symbol table manipulation seems a bit magical to 
me.

Just brainstorming here, but why not an __autoload for functions?

---

## #15761 — Zeev Suraski — 2005-04-03T14:39:39+00:00

URL: https://externals.io/message/15739#15761 · In reply to: #15739

At 18:31 03/04/2005, Marcus Boerger wrote:
>Right from the beginning i said __autoload() is just wrong and we need the
>described behavior. However all i got back is that i am just wrong and we
>don't need it. And that from everybody. But since SPL already gives all
>you mentioned there is no reason to do anything more.
>
>I'll come back here once i have my Montreal slides online which documnets
>everthing or i may also find time to do documentation soon.

Marcus,

Regardless of what happened, I don't see how this piece of functionality 
belongs in SPL.  SPL isn't a backdoor for introducing whatever you want 
into PHP without discussion, is it? :)

Zeev

---

## #15764 — Zeev Suraski — 2005-04-03T14:46:29+00:00

URL: https://externals.io/message/15739#15764 · In reply to: #15739

Alan,

Your blog entry is actually what made me look into that topic.  I'm not 
sure whether I agree with you regarding the general necessity of 
__autoload().  __autoload() is not only about saving the headache of 
explicit require()'s, it's also about 'JITing' this task, so that no 
classes are loaded unless you actually use them.

The main things I took from there are that __autoload() is broken since 
it's limited to just one declaration, and that somehow an alternative was 
introduced into SPL, which is slightly scary.

Zeev

At 15:58 03/04/2005, Alan Knowles wrote:
>I dont know if you read the blog comments here:
>http://www.akbkhome.com/blog.php/View/79/require_once+is+part+of+your
>+documentation..html
>and here
>http://www.akbkhome.com/blog.php/View/77/is+__autoload+evil%3F.html
>
>and slightly related
>http://www.akbkhome.com/blog.php/View/76/require_once%2C+one
>+optimization+too+many%3F.html
>
>It's pretty clear that people want to use autoload to save them having
>to deal with include paths.. (and perhaps save a few stat calls) - the
>more straightforward solution would be to add a include/require callback
>handler - so that rather than a class instantation action, magically
>doing file operations, you had a simpler and more obvious way to manage
>inclusions.
>
>But I guess Until I bother hacking something up for it, it'll remain
>little more than another heckle from the audience. ;)
>
>Regards
>Alan
>
>
> > […]
> __autoload(), is
> > […]
> may
> > […]
> issue #1).
> > […]

---

## #15758 — Greg Beaver — 2005-04-03T14:51:04+00:00

URL: https://externals.io/message/15739#15758 · In reply to: #15739

Zeev Suraski wrote:
> All,
> 
> One problem that became apparent after the introduction of __autoload(), 
> is that different pieces of code, sometimes coming from different 
> sources, may want to declare this function in a different way.  Today, 
> __autoload() is treated like any other function, so it's impossible to 
> re-declare it.
> 
> Marcus tried to solve it by introducing an __autoload() wrapper in SPL.  
> Personally I think it's probably not the right way to go, but that's 
> beside the point right now.
> 
> What I'd like to suggest is a change in the behavior of __autoload(), so 
> that multiple __autoload()'s could be defined.  Essentially, declaring 
> __autoload() would in fact add the function to the list of functions 
> that are called in case a missing class is referenced.  However, it will 
> not actually place a function named __autoload() in the PHP function 
> table.  That way, it would be possible to declare multiple 
> __autoloads(), and have all of them called when a missing class is spotted.
> 
> The two issues with this solution are:
> 
> 1.  It will be impossible to use the standard means to determine whether 
> __autoload() is declared or not.  I don't think that's a very important 
> issue but it's there nonetheless.
> 2.  We need to determine what makes sense as far as calling order if we 
> have more than one __autoload().  My guess would be calling them in the 
> order they were registered, and checking whether the class was defined 
> after each one (if it was - stop).
> 
> That solution maintains downwards compatibility (almost, other than 
> issue #1).
> 
> Thoughts?

Don't forget

3. If a library has an obscure bug in __autoload, the only error message 
the user will see is:

"undefined class XXXX"

If __autoload() is going to gain the ability to be defined for a 
library, then the error messages must be enhanced as well.

There is a possible solution:

1) document that coders of __autoload() should throw an 
autoload_exception if a class is not found

How difficult would it be to have a zend_autoload_throw() that would 
bubble up to the next __autoload() and save the exceptions in a hash for 
later display if necessary (exceptions need not be the actual 
implementation, obviously)?  This way, each exception message thrown by 
an autoload could be displayed after the "undefined class XXXX", 
eliminating a large portion of the magic that makes debugging multiple 
__autoload() impossible right now.

Greg

---

## #15760 — Marcus Boerger — 2005-04-03T15:31:06+00:00

URL: https://externals.io/message/15739#15760 · In reply to: #15739

Hello Zeev,

Sunday, April 3, 2005, 6:05:22 AM, you wrote:

> All,

> One problem that became apparent after the introduction of __autoload(), is
> that different pieces of code, sometimes coming from different sources, may
> want to declare this function in a different way.  Today, __autoload() is 
> treated like any other function, so it's impossible to re-declare it.

> Marcus tried to solve it by introducing an __autoload() wrapper in 
> SPL.  Personally I think it's probably not the right way to go, but that's
> beside the point right now.

I did not try to get it fixed i just fixed it (dot).

Right from the beginning i said __autoload() is just wrong and we need the
described behavior. However all i got back is that i am just wrong and we
don't need it. And that from everybody. But since SPL already gives all
you mentioned there is no reason to do anything more.

I'll come back here once i have my Montreal slides online which documnets
everthing or i may also find time to do documentation soon.

best regards
marcus

---

## #15766 — Andi Gutmans — 2005-04-03T16:01:02+00:00

URL: https://externals.io/message/15739#15766 · In reply to: #15739

At 11:31 AM 4/3/2005 -0400, Marcus Boerger wrote:
>I did not try to get it fixed i just fixed it (dot).
>
>Right from the beginning i said __autoload() is just wrong and we need the
>described behavior. However all i got back is that i am just wrong and we
>don't need it. And that from everybody. But since SPL already gives all
>you mentioned there is no reason to do anything more.
>
>I'll come back here once i have my Montreal slides online which documnets
>everthing or i may also find time to do documentation soon.

Well I think the point is that you were right that the current way 
__autoload() works is not good enough.
I don't think the right solution though is to leave the not-optimal 
solution in the engine, and create a solution outside the engine. I think 
we should find a way to tune the engine so that it works well. Zeev's 
suggestion keeps BC. If there are concerns as far as chaining order are 
concerned, I personally don't have a problem supplying an API function 
where functions can be added programmatically.
We'd then get the best of both worlds and make it very accessible by everyone.

Andi

---

## #15772 — Marcus Boerger — 2005-04-03T21:54:30+00:00

URL: https://externals.io/message/15739#15772 · In reply to: #15761

Hello Zeev,

Sunday, April 3, 2005, 10:39:39 AM, you wrote:

> At 18:31 03/04/2005, Marcus Boerger wrote:
> > […]

> Marcus,

> Regardless of what happened, I don't see how this piece of functionality 
> belongs in SPL.  SPL isn't a backdoor for introducing whatever you want 
> into PHP without discussion, is it? :)

No, it's the place where i do my stuff and stuff others want to have also.
And it is the place i am responsible for. And since it is all about making
use of php's new object orientation it is a very good place to put advanced
stuff into.

-- 
Best regards,
 Marcus                            mailto:mail@marcus-boerger.de

---

## #15775 — Adam Maccabee Trachtenberg — 2005-04-04T00:47:07+00:00

URL: https://externals.io/message/15739#15775 · In reply to: #15766

> I don't think the right solution though is to leave the not-optimal
> solution in the engine, and create a solution outside the engine. I think
> we should find a way to tune the engine so that it works well. Zeev's
> suggestion keeps BC. If there are concerns as far as chaining order are
> concerned, I personally don't have a problem supplying an API function
> where functions can be added programmatically.
> We'd then get the best of both worlds and make it very accessible by everyone.

FWIW, I don't think maintaining BC is super important here. I don't
believe lots of people are using __autoload() currently, and it should
be pretty trivial to migrate to whatever solution we end up with.

I would prefer we concentrate on getting the __autoload() behavior
that we think is right. If we can do both, then that's a win-win, but
we shouldn't let BC get in the way here for the two reasons I outlined
above.

Also, from a timing perspective, if we are modifying __autoload(), I
would suggest that PHP 5.1 would be the correct place to introduce it.

Finally, on the point of "does order matter?" I think order does
matter.

I may want to pull classes from a general framework (such as PEAR)
and also from my own personal set of classes. I don't want to
accidently include a PEAR class that has the same name as my own
class.

I believe Andrey's reference to include_path (or the PATH variable in
your shell) is a good one. What if we said developers can't rely on
the order of their path? The feature would be far less useful because
of clashes.

-adam

-- 
adam@trachtenberg.com | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!

---

## #15787 — Derick Rethans — 2005-04-04T07:40:30+00:00

URL: https://externals.io/message/15739#15787 · In reply to: #15775

> 
> 
> > […]
> 
> FWIW, I don't think maintaining BC is super important here. I don't
> believe lots of people are using __autoload() currently, and it should
> be pretty trivial to migrate to whatever solution we end up with.

BC is always important.

Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

---

## #15788 — Lukas Smith — 2005-04-04T07:41:46+00:00

URL: https://externals.io/message/15739#15788 · In reply to: #15751

Alan Knowles wrote:
> I dont know if you read the blog comments here:
> http://www.akbkhome.com/blog.php/View/79/require_once+is+part+of+your
> +documentation..html
> and here
> http://www.akbkhome.com/blog.php/View/77/is+__autoload+evil%3F.html
> 
> and slightly related
> http://www.akbkhome.com/blog.php/View/76/require_once%2C+one
> +optimization+too+many%3F.html
> 
> It's pretty clear that people want to use autoload to save them having
> to deal with include paths.. (and perhaps save a few stat calls) - the
> more straightforward solution would be to add a include/require callback
> handler - so that rather than a class instantation action, magically
> doing file operations, you had a simpler and more obvious way to manage
> inclusions.
> 
> But I guess Until I bother hacking something up for it, it'll remain
> little more than another heckle from the audience. ;)

Frameworks should provide __autoload() helper methods, but should never 
implement the function itself. Its upto the enduser to do this. This is 
the only way it makes sense. Otherwise most of Alan's horror scenarios 
actually come true. The cleanest way indeed is to be able to set the 
function name for autoloading as a callback. We we have this now via 
spl. So I dont see a point messing with it and thereby making this tool 
unmaintainable and totaly inconsistent with the reset of the language. I 
can already see it .. in 5 years there will be books on php __autoload().

regards,
Lukas

---

## #15791 — Stanislav Malyshev — 2005-04-04T13:47:22+00:00

URL: https://externals.io/message/15739#15791 · In reply to: #15758

GB>>3. If a library has an obscure bug in __autoload, the only error message 
GB>>the user will see is:
GB>>
GB>>"undefined class XXXX"
GB>>
GB>>If __autoload() is going to gain the ability to be defined for a 
GB>>library, then the error messages must be enhanced as well.

Shouldn't that bug result in some error message by itself? If it doesn't, 
there's probably nothing to add to "undefined class" anyway.

GB>>1) document that coders of __autoload() should throw an 
GB>>autoload_exception if a class is not found

Why just not return false or something? Exception is supposed to be used 
when things are so bad you just can not continue. But I don't think class 
not being found is such situation for autoload.

On the other hand, I think that multiple autoload functions should be 
evaluated in isoplated way - so that exception, etc. in one of them would 
terminate it, but not the whole autoload process (i.e., next one would be 
run).
-- 
Stanislav Malyshev, Zend Products Engineer   
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

---

## #15793 — Adam Maccabee Trachtenberg — 2005-04-04T14:27:09+00:00

URL: https://externals.io/message/15739#15793 · In reply to: #15787

> > […]
>
> BC is always important.

I didn't say it wasn't important. I said it wasn't "super
important". :)

-adam

-- 
adam@trachtenberg.com | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!

---

## #15794 — Greg Beaver — 2005-04-04T15:27:56+00:00

URL: https://externals.io/message/15739#15794 · In reply to: #15791

Stanislav Malyshev wrote:
> GB>>3. If a library has an obscure bug in __autoload, the only error message 
> GB>>the user will see is:
> GB>>
> GB>>"undefined class XXXX"
> GB>>
> GB>>If __autoload() is going to gain the ability to be defined for a 
> GB>>library, then the error messages must be enhanced as well.
> 
> Shouldn't that bug result in some error message by itself? If it doesn't, 
> there's probably nothing to add to "undefined class" anyway.

I meant a logic error - as in the user forgot to use a 
 `DIRECTORY_SEPARATOR` and so can't find any of the classes, not an obvious 
PHP error.

> 
> GB>>1) document that coders of __autoload() should throw an 
> GB>>autoload_exception if a class is not found
> 
> Why just not return false or something? Exception is supposed to be used 
> when things are so bad you just can not continue. But I don't think class 
> not being found is such situation for autoload.
> 
> On the other hand, I think that multiple autoload functions should be 
> evaluated in isoplated way - so that exception, etc. in one of them would 
> terminate it, but not the whole autoload process (i.e., next one would be 
> run).

Perhaps a better solution is to simply augment the "undefined class XXX" 
method with a brief listing of all the defined __autoload() functions, 
so the user knows where to look for magic bugs.

Greg

---

## #15795 — Stanislav Malyshev — 2005-04-04T16:02:16+00:00

URL: https://externals.io/message/15739#15795 · In reply to: #15794

GB>>I meant a logic error - as in the user forgot to use a
GB>>DIRECTORY_SEPARATOR and so can't find any of the classes, not an
GB>>obvious PHP error.

OK - then how exactly you want the error message look like? How the engine 
is going to guess if it was `DIRECTORY_SEPARATOR` missing or the class was 
genuinely missing?

GB>>Perhaps a better solution is to simply augment the "undefined class XXX" 
GB>>method with a brief listing of all the defined __autoload() functions, 
GB>>so the user knows where to look for magic bugs.

What, you mean output all autoloading functions? Why? If you defined them, 
you know them, if you didn't, you shouldn't count on them to be there 
anyway. And what exactly this listing would reveal to you? You couldn't 
find a bug just looking on the names.
-- 
Stanislav Malyshev, Zend Products Engineer   
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

---

## #15796 — Andrey Hristov — 2005-04-04T16:47:01+00:00

URL: https://externals.io/message/15739#15796 · In reply to: #15795

Stanislav Malyshev wrote:
> GB>>I meant a logic error - as in the user forgot to use a
> GB>>DIRECTORY_SEPARATOR and so can't find any of the classes, not an
> GB>>obvious PHP error.
> 
> OK - then how exactly you want the error message look like? How the engine 
> is going to guess if it was `DIRECTORY_SEPARATOR` missing or the class was 
> genuinely missing?
> 
> GB>>Perhaps a better solution is to simply augment the "undefined class XXX" 
> GB>>method with a brief listing of all the defined __autoload() functions, 
> GB>>so the user knows where to look for magic bugs.
> 
> What, you mean output all autoloading functions? Why? If you defined them, 
> you know them, if you didn't, you shouldn't count on them to be there 
> anyway. And what exactly this listing would reveal to you? You couldn't 
> find a bug just looking on the names.
  Stanislav,
Greg probable means something like a stack trace of the autload callbacks
that were called. This will be a nice addition just like Exception stacktraces
are (I wish there were stacktraces for Fatal errors).

Andrey

---

## #15798 — Greg Beaver — 2005-04-04T18:04:47+00:00

URL: https://externals.io/message/15739#15798 · In reply to: #15796

Andrey Hristov wrote:
>  Stanislav,
> Greg probable means something like a stack trace of the autload callbacks
> that were called. This will be a nice addition just like Exception 
> stacktraces
> are (I wish there were stacktraces for Fatal errors).

yes, a stack trace would be ideal - I knew there was a name for that 
thing I was describing :)

Greg

---

## #15800 — Marcus Boerger — 2005-04-04T18:37:02+00:00

URL: https://externals.io/message/15739#15800 · In reply to: #15798

Hello Greg,

Monday, April 4, 2005, 2:04:47 PM, you wrote:

> Andrey Hristov wrote:
> > […]

> yes, a stack trace would be ideal - I knew there was a name for that 
> thing I was describing :)

> Greg


SPl offers a function to check all registered functions. Since a missing
class would require all those functions to fail that's all you need to know.
And i think we can somehow even allow exceptions. I think it actually works
right now already but i have to check....will do so one the flight home

Best regards,
 Marcus                            mailto:mail@marcus-boerger.de

---

## #15810 — Marcus Boerger — 2005-04-05T09:43:11+00:00

URL: https://externals.io/message/15739#15810 · In reply to: #15798

Hello Greg,

Monday, April 4, 2005, 2:04:47 PM, you wrote:

> Andrey Hristov wrote:
> > […]

> yes, a stack trace would be ideal - I knew there was a name for that 
> thing I was describing :)

A stack trace is only some additional information that has no real added
information. Also it is not a real stack trace since what you asked is
just a list of functions called at one level and not the trace up to
that part where a class was missing (which would be a stack trace).

After my last commit you can get a stack trace by throwing an exception
in the last called function. To get a list of all functions being called
just check `spl_autoload_functions()`.

A combination of both would require the engine to be changed to be capable
of handling multiple exceptions - which hopefully we do not want. Right
now a second exception while an exception is already pending results in a
fatal error.

-- 
Best regards,
 Marcus                            mailto:mail@marcus-boerger.de

---

## #15815 — Greg Beaver — 2005-04-05T14:55:12+00:00

URL: https://externals.io/message/15739#15815 · In reply to: #15810

Marcus Boerger wrote:
> Hello Greg,
> 
> Monday, April 4, 2005, 2:04:47 PM, you wrote:
> 
> 
> > […]
> 
> 
> > […]
> 
> 
> A stack trace is only some additional information that has no real added
> information. Also it is not a real stack trace since what you asked is
> just a list of functions called at one level and not the trace up to
> that part where a class was missing (which would be a stack trace).

I imagined that a failed __autoload() would leave the old on one the 
call stack, as if the user had inserted the call to the new __autoload() 
before the last closing }.

> After my last commit you can get a stack trace by throwing an exception
> in the last called function. To get a list of all functions being called
> just check `spl_autoload_functions()`.

The exception solution will only work if the user puts a throw() in 
there.  The list of functions would be more useful, imo.

> A combination of both would require the engine to be changed to be capable
> of handling multiple exceptions - which hopefully we do not want. Right
> now a second exception while an exception is already pending results in a
> fatal error.

I don't think putting exceptions into __autoload is a good idea at all, 
the only use exceptions serve is to bubble out of contexts, whereas an 
undefined class will simply error out.  Simpler is to provide an option 
for users to define an error handler that can display the __autoload() 
functions used with some kind of listing function, whether it is 
 `spl_autoload_functions()` or an engine feature.

Greg

---

## #15816 — Stanislav Malyshev — 2005-04-05T14:58:09+00:00

URL: https://externals.io/message/15739#15816 · In reply to: #15815

GB>>call stack, as if the user had inserted the call to the new
GB>>__autoload()  before the last closing }.

Too much magic, IMO. All you need to know is the list of functions, you 
don't need any 'stack' since they do not call each one.

-- 
Stanislav Malyshev, Zend Products Engineer   
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

---

Next page: https://externals.io/message/15739.md?page=2