__autoload() enhancement

Andrey Hristov

21 years ago

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

Andrey

Zeev Suraski

21 years ago

At 14:21 03/04/2005, Andrey Hristov wrote:

>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,
>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

Andrey Hristov

21 years ago

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

Zeev Suraski

21 years ago

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

Andrey Hristov

21 years ago

Zeev Suraski wrote:

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

That´s ok too.

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

I have seen systems where the include_path is used to overwrite classes.
What do you I mean? There is a core functionality and for a specific project
the core classes can be overwritten by putting them forward in the include_path.
I don´t like this solution but this is probably the only one existing one
and the only one existing for quite a lot of time. If there is ordered execution
of __autload() then the project specific __autoload() will be executed first and
try to load from it´s part if not, returns and __autoload() of the core
will try to load.
I am not a Java profi but I think that Java had similar functionality of managers
which are organized in a tree structure. Probably we don´t need a tree structure but
I think the possibility to register own function as autload one is a good idea.
Therefore, instead of allowing the user to define multiple __autoload() he can do

function thisModule__autoload() {
...

}
register_autoload_function(´thisModule__autoload´);

Of course one call more, but in the cases one wants to have ordered execution
of the autoload funcs he may implement it. For the people it does not matter it
won´t make their life harder.


Andrey

Alan Knowles

21 years ago

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

On Sun, 2005-04-03 at 13:05 +0300, Zeev Suraski wrote:

Lukas Smith

21 years ago

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

Jeff Moore

21 years ago

On Apr 3, 2005, at 6:05 AM, Zeev Suraski wrote:

> 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?

Greg Beaver

21 years ago

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

Stanislav Malyshev

21 years ago

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

Greg Beaver

21 years ago

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

Stanislav Malyshev

21 years ago

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

Andrey Hristov

21 years ago

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

Greg Beaver

21 years ago

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

Marcus Boerger

21 years ago

Hello Greg,

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

> 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

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

Marcus Boerger

21 years ago

Hello Greg,

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

> 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 :)

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

Greg Beaver

21 years ago

Marcus Boerger wrote:

> Hello Greg,
>
> Monday, April 4, 2005, 2:04:47 PM, you wrote:
>
>
>>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 :)
>
>
> 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

Stanislav Malyshev

21 years ago

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

Marcus Boerger

21 years ago

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

Zeev Suraski

21 years ago

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

Marcus Boerger

21 years ago

Hello Zeev,

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

> 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? :)

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

Zeev Suraski

21 years ago

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:

Andi Gutmans

21 years ago

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

Adam Maccabee Trachtenberg

21 years ago

On Sun, 3 Apr 2005, Andi Gutmans wrote:

> 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!

Derick Rethans

21 years ago

On Sun, 3 Apr 2005, Adam Maccabee Trachtenberg wrote:

> On Sun, 3 Apr 2005, Andi Gutmans wrote:
>
> > 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.

BC is always important.

Derick

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

Adam Maccabee Trachtenberg

21 years ago

On Mon, 4 Apr 2005, Derick Rethans wrote:

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

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!