FAQ
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

Search Discussions

  • Andrey Hristov at Apr 3, 2005 at 11:21 am

    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 at Apr 3, 2005 at 11:53 am

    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 at Apr 3, 2005 at 12:18 pm

    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 at Apr 3, 2005 at 12:22 pm

    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 at Apr 3, 2005 at 12:41 pm

    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 at Apr 3, 2005 at 12:56 pm
    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:
    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
  • Zeev Suraski at Apr 3, 2005 at 3:46 pm
    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
    On Sun, 2005-04-03 at 13:05 +0300, 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
  • Lukas Smith at Apr 4, 2005 at 7:41 am

    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 at Apr 3, 2005 at 2:24 pm

    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 at Apr 3, 2005 at 2:51 pm

    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 at Apr 4, 2005 at 1:47 pm
    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 at Apr 4, 2005 at 3:28 pm

    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 at Apr 4, 2005 at 4:02 pm
    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 at Apr 4, 2005 at 4:48 pm

    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 at Apr 4, 2005 at 6:05 pm

    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 at Apr 4, 2005 at 6:37 pm
    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 at Apr 5, 2005 at 9:43 am
    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 at Apr 5, 2005 at 2:55 pm

    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 at Apr 5, 2005 at 2:58 pm
    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
  • Andrey Hristov at Apr 5, 2005 at 3:21 pm

    Stanislav Malyshev wrote:
    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,
    a stack is a list and a list is a stack, right ? :)

    Andrey
  • Marcus Boerger at Apr 5, 2005 at 3:30 pm
    Hello Andrey,

    Tuesday, April 5, 2005, 5:21:17 PM, you wrote:
    Stanislav Malyshev wrote:
    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.
    I completeley agree with Stanislav here, way to much magic: The engine
    should never fumble around with a trace before making it accessible.
    Stanislav,
    a stack is a list and a list is a stack, right ? :)
    Wrong, by list we mean all registered autoload functions which
    can be retrived by 'print_r(spl_autoload_functions())' and the
    stack trace from main to the autoload call.

    --
    Best regards,
    Marcus mailto:mail@marcus-boerger.de
  • Andrey Hristov at Apr 5, 2005 at 3:32 pm

    Marcus Boerger wrote:
    Hello Andrey,

    Tuesday, April 5, 2005, 5:21:17 PM, you wrote:

    Stanislav Malyshev wrote:
    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.
    I completeley agree with Stanislav here, way to much magic: The engine
    should never fumble around with a trace before making it accessible.
    Stanislav,
    a stack is a list and a list is a stack, right ? :)

    Wrong, by list we mean all registered autoload functions which
    can be retrived by 'print_r(spl_autoload_functions())' and the
    stack trace from main to the autoload call.
    Marcus,
    for the record, he mentioned stack not stacktrace :)

    Andrey
  • Marcus Boerger at Apr 3, 2005 at 3:31 pm
    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 at Apr 3, 2005 at 3:39 pm

    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 at Apr 3, 2005 at 9:54 pm
    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
  • Andi Gutmans at Apr 3, 2005 at 4:01 pm

    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 at Apr 4, 2005 at 12:47 am

    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 at Apr 4, 2005 at 7:40 am

    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
  • Adam Maccabee Trachtenberg at Apr 4, 2005 at 2:27 pm

    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!

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedApr 3, '05 at 11:05a
activeApr 5, '05 at 3:32p
posts30
users11
websitephp.net

People

Translate

site design / logo © 2022 Grokbase