FAQ
Ahoi,

I have written an RFC for a more efficient solution to get rid of the
common fopen() hack inside autoloaders:
if ($fp = @fopen($file, 'r', true)) {
fclose($fp);
include $file;
}

Here is the gist of the proposal:
In order to solve the above issues this RFC proposes the addition of a
new construct/function for now called “autoload_include” for lack of a
better name that largely behaves like the “include” does today with
the following differences, that when the include failed because of a
missing file no warning is raised and php null is returned.

Further details can be found on the wiki:
http://wiki.php.net/rfc/autoload_include

As stated in the RFC, I am not happy with the name "autoload_include".
Suggestions welcome!

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

Search Discussions

  • Guilherme Blanco at Nov 10, 2009 at 5:01 pm
    include_silent is the name I though most intuitive once I finished to
    read the RFC.

    But it may not be the best too. It just need to be verbose.

    Cheers,
    On Tue, Nov 10, 2009 at 2:45 PM, Lukas Kahwe Smith wrote:
    Ahoi,

    I have written an RFC for a more efficient solution to get rid of the common
    fopen() hack inside autoloaders:
    if ($fp = @fopen($file, 'r', true)) {
    fclose($fp);
    include $file;
    }

    Here is the gist of the proposal:
    In order to solve the above issues this RFC proposes the addition of a new
    construct/function for now called “autoload_include” for lack of a better
    name that largely behaves like the “include” does today with the following
    differences, that when the include failed because of a missing file no
    warning is raised and php null is returned.

    Further details can be found on the wiki:
    http://wiki.php.net/rfc/autoload_include

    As stated in the RFC, I am not happy with the name "autoload_include".
    Suggestions welcome!

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org




    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Guilherme Blanco - Web Developer
    CBC - Certified Bindows Consultant
    Cell Phone: +55 (16) 9215-8480
    MSN: guilhermeblanco@hotmail.com
    URL: http://blog.bisna.com
    São Paulo - SP/Brazil
  • Stanislav Malyshev at Nov 10, 2009 at 6:49 pm
    Hi!
    In order to solve the above issues this RFC proposes the addition of a new
    construct/function for now called “autoload_include” for lack of a better
    name that largely behaves like the “include” does today with the following
    differences, that when the include failed because of a missing file no
    warning is raised and php null is returned.
    Maybe it'd be easier to just add parameter to file_exists that allows it
    to use include_path? I think that's at least what ZF is trying to do
    with that fopen - it tries to find out if such file exists in the path
    and if so - include it.
    I don't think you need to create special language construct for that -
    you can shut off warning with @.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Lukas Kahwe Smith at Nov 10, 2009 at 6:57 pm

    On 10.11.2009, at 19:49, Stanislav Malyshev wrote:

    Hi!
    In order to solve the above issues this RFC proposes the addition
    of a new
    construct/function for now called “autoload_include” for lack of a
    better
    name that largely behaves like the “include” does today with the
    following
    differences, that when the include failed because of a missing
    file no
    warning is raised and php null is returned.
    Maybe it'd be easier to just add parameter to file_exists that
    allows it to use include_path? I think that's at least what ZF is
    trying to do with that fopen - it tries to find out if such file
    exists in the path and if so - include it.
    I don't think you need to create special language construct for that
    - you can shut off warning with @.

    yes that would solve the issue partially. the race condition would
    still remain, but its admitedly a rare case .. well I guess not so
    rare if you have a busy site and try to implement some caching for
    generated files .. then again these kinds of files are rarely loaded
    via autoload (probably more used for some generated arrays and stuff
    like that). it would also not solve the imho needless file system
    operations.

    that being said, i brought up adding such a flag to file_exists() a
    few times before and each attempt has been shot down saying that fopen
    () should have never gotten this flag and this portion of the code
    should not mess with the include path.

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
  • Stanislav Malyshev at Nov 10, 2009 at 7:07 pm
    Hi!
    yes that would solve the issue partially. the race condition would still
    remain, but its admitedly a rare case .. well I guess not so rare if you
    I would have hard time thinking of application that deletes its own
    include files frequently from other processes and we are supposed to
    handle that deterministically. But even then worst thing would happen is
    that include fails.
    (probably more used for some generated arrays and stuff like that). it
    would also not solve the imho needless file system operations.
    You could cache file_exists using all kinds of external caching
    mechanisms if you want to.
    that being said, i brought up adding such a flag to file_exists() a few
    times before and each attempt has been shot down saying that fopen()
    should have never gotten this flag and this portion of the code should
    not mess with the include path.
    Why fopen() should have never gotten this flag? I don't remember any
    argument on that. Also, if we have include path I see no reason why we
    shouldn't have code that can work with it.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Lukas Kahwe Smith at Nov 10, 2009 at 7:16 pm

    On 10.11.2009, at 20:07, Stanislav Malyshev wrote:

    Hi!
    yes that would solve the issue partially. the race condition would
    still remain, but its admitedly a rare case .. well I guess not so
    rare if you
    I would have hard time thinking of application that deletes its own
    include files frequently from other processes and we are supposed to
    handle that deterministically. But even then worst thing would
    happen is that include fails.
    there are many approaches to caching, one of which is delete to
    invalidate and regenerate before the next use. again as the RFC makes
    it clear .. the purpose is to be able to differentiate between a
    syntax error and a missing file.
    (probably more used for some generated arrays and stuff like that).
    it would also not solve the imho needless file system operations.
    You could cache file_exists using all kinds of external caching
    mechanisms if you want to.
    sure .. but that requires yet more code. but in that case i might as
    well iterate over the include path to be able to determine the
    absolute path and cache that, which is something i also want to enable
    in an efficient manner with the optional addition of returning the
    file loaded instead of true in case the file does not return anything
    explicitly. again something that i mentioned in the RFC.
    that being said, i brought up adding such a flag to file_exists() a
    few times before and each attempt has been shot down saying that
    fopen() should have never gotten this flag and this portion of the
    code should not mess with the include path.
    Why fopen() should have never gotten this flag? I don't remember any
    argument on that. Also, if we have include path I see no reason why
    we shouldn't have code that can work with it.

    IIRC Derick was one of the most vocal against adding this to
    file_exists() and complaining about the fact that its even available
    for fopen().

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
  • Stanislav Malyshev at Nov 10, 2009 at 7:38 pm
    Hi!
    there are many approaches to caching, one of which is delete to
    invalidate and regenerate before the next use. again as the RFC makes it
    clear .. the purpose is to be able to differentiate between a syntax
    error and a missing file.
    If you writing your own cache basing on includes, you can write sequence
    that handles deletion correctly, knows if your own data exist or not and
    doesn't need include path functions for that.
    sure .. but that requires yet more code. but in that case i might as
    More functionality requires more code. I think it's better than turning
    the language into kitchen sink of similar language constructs, each has
    a little tweak to suit one particular use case. Next thing we would have
    framework_include, database_include, template_system_include,
    my_personal_homepage_include and so on. I think we need to do very
    generic stuff in the language, less generic in functions and yet less
    generic - in user code.
    well iterate over the include path to be able to determine the absolute
    path and cache that, which is something i also want to enable in an
    efficient manner with the optional addition of returning the file loaded
    instead of true in case the file does not return anything explicitly.
    again something that i mentioned in the RFC.
    We could also have function file_find() (or any other name, let the
    bikeshedding begin) or something that would resolve filename against
    include path and return full name if such exists or false if none
    exists. That seems generic enough operation to have a function for.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Lukas Kahwe Smith at Nov 10, 2009 at 7:48 pm

    On 10.11.2009, at 20:38, Stanislav Malyshev wrote:

    there are many approaches to caching, one of which is delete to
    invalidate and regenerate before the next use. again as the RFC
    makes it clear .. the purpose is to be able to differentiate
    between a syntax error and a missing file.
    If you writing your own cache basing on includes, you can write
    sequence that handles deletion correctly, knows if your own data
    exist or not and doesn't need include path functions for that.
    sure .. but that requires yet more code. but in that case i might as
    More functionality requires more code. I think it's better than
    turning the language into kitchen sink of similar language
    constructs, each has a little tweak to suit one particular use case.
    Next thing we would have framework_include, database_include,
    template_system_include, my_personal_homepage_include and so on. I
    think we need to do very generic stuff in the language, less generic
    in functions and yet less generic - in user code.
    well imho neither require nor include have been written with the
    "right" API in mind to solve todays needs. for all i care we could
    also break BC for include and adjust it according to my proposal in
    PHP6.

    anyways .. you are glossing over several draw backs in the current
    possible approaches, each saying you can solve that in user land with
    more code. yet my proposal would be a tiny change in php core
    (probably alot of code could be shared) and would still surpass the
    user land approaches. i do not know if there is anything possible to
    make include itself more flexible since its a language construct and
    not a "normal" function.
    well iterate over the include path to be able to determine the
    absolute path and cache that, which is something i also want to
    enable in an efficient manner with the optional addition of
    returning the file loaded instead of true in case the file does not
    return anything explicitly. again something that i mentioned in the
    RFC.
    We could also have function file_find() (or any other name, let the
    bikeshedding begin) or something that would resolve filename against
    include path and return full name if such exists or false if none
    exists. That seems generic enough operation to have a function for.

    ok .. so your objection to the RFC is solely because it introduces a
    new language construct?

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
  • Stanislav Malyshev at Nov 10, 2009 at 8:31 pm
    Hi!
    ok .. so your objection to the RFC is solely because it introduces a new
    language construct?
    No, my objection is that it is not necessary to introduce a language
    construct, and the construct introduced is not the right one. If
    frameworks want to find out if file exists or get its name - we should
    give them API to do that. If they want just to silence the errors - they
    already have the construct to do that.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Lukas Kahwe Smith at Nov 10, 2009 at 8:56 pm

    On 10.11.2009, at 21:31, Stanislav Malyshev wrote:

    ok .. so your objection to the RFC is solely because it introduces
    a new language construct?
    No, my objection is that it is not necessary to introduce a language
    construct, and the construct introduced is not the right one. If
    frameworks want to find out if file exists or get its name - we
    should give them API to do that. If they want just to silence the
    errors - they already have the construct to do that.

    They dont want to determine if a file exists. They want to be able to
    handle the case of a missing file being included differently than a
    syntax error. Since php core does not provide such features, the only
    way to do this is using the fopen() hack, iterating over the include
    path .. or I guess track errors with @. My proposal actually makes it
    possible to do what the frameworks need with less overhead. There is
    no way to do what these frameworks need inside userland without the
    above mentioned hacks. The fact that almost all frameworks are forced
    to use these hacks and quite a significant number of developers use
    frameworks (resulting in quite a number of apps end users install also
    using these frameworks) implies that we are not talking about an edge
    case here.

    Now I also made it clear that its not about blindly silencing "errors"
    but there is a need to differentiate between different error causes.
    Of course having to use @ for such a common use case is also not
    ideal. Its just that the error handling we provide internally isnt
    really able to handle this scenario well:

    1) checking before adds overhead and opens issue with potential race
    conditions
    2) silencing the error and using track errors adds overhead and
    potential issues with custom error handlers

    Anyways, lets see if there are other comments in the coming days. I
    think you have made your priorities clear. At least I understand them,
    but do not share them.

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
  • Stanislav Malyshev at Nov 10, 2009 at 9:28 pm
    Hi!
    They dont want to determine if a file exists. They want to be able to
    handle the case of a missing file being included differently than a
    syntax error. Since php core does not provide such features, the only
    Let's see why they need to handle missing file being included
    differently? Or, even more interestingly - why they need to include file
    that is missing if they know they'd have to do something different?
    Maybe they would want to know if file exists or nor before trying to
    include it, because they don't know which exactly file they are going to
    include?
    The goal here, at least for ZF, is to find the right file and include
    it. Both APIs that I proposed allow to express it directly - find file
    and include it. Your API would make them do it through chain of trial
    and error by trying to include a string of non-existing files before
    actually trying a successful one, thus mixing three functions - finding
    files, including files and error reporting - into one. How it's better?
    possible to do what the frameworks need with less overhead. There is no
    way to do what these frameworks need inside userland without the above
    mentioned hacks. The fact that almost all frameworks are forced to use
    I just showed you at least two different ways to do it, with different
    APIs. You may not agree it's right APIs but please don't make it appear
    as your solution is only possible one in existence. It is not.
    Now I also made it clear that its not about blindly silencing "errors"
    but there is a need to differentiate between different error causes. Of
    How you are going to differentiate? Your proposal only has one return
    value (null) which is conveniently coincides with return value that can
    be produced by include too by doing return;. You don't know why it
    failed, you don't even really know did it fail or not. You just know you
    got null in return.
    1) checking before adds overhead and opens issue with potential race
    conditions
    I don't think it's real use case - please show me one framework that
    uses plugin includes through include path while other processes are
    deleting their plugins randomly. I think you are trying to solve
    non-existing problem here. Caching/templating APIs usually know exactly
    where their files are and don't need to look for them in include path.
    2) silencing the error and using track errors adds overhead and
    potential issues with custom error handlers
    Again, what frameworks need is to find the right file among variety of
    possibilities in include path and then include it. I think it can be
    well served by using existing "include" with addition of "find" API and
    there's no necessity for new language construct to serve one specific
    use case. In a month, some framework would have slightly different use
    case and you'd invent another packaged language construct for this?
    There's a reason why language constructs tend to be primitive - because
    you can assemble a lot of use cases from simple primitives, but it's
    hard to deal with use-case-tailored constructs. We have four inclusion
    constructs in language as it is, I think it's enough.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Lukas Kahwe Smith at Nov 10, 2009 at 10:10 pm

    On 10.11.2009, at 22:28, Stanislav Malyshev wrote:

    Hi!
    They dont want to determine if a file exists. They want to be able
    to handle the case of a missing file being included differently
    than a syntax error. Since php core does not provide such features,
    the only
    Let's see why they need to handle missing file being included
    differently? Or, even more interestingly - why they need to include
    file that is missing if they know they'd have to do something
    different? Maybe they would want to know if file exists or nor
    before trying to include it, because they don't know which exactly
    file they are going to include?
    The goal here, at least for ZF, is to find the right file and
    include it. Both APIs that I proposed allow to express it directly -
    find file and include it. Your API would make them do it through
    chain of trial and error by trying to include a string of non-
    existing files before actually trying a successful one, thus mixing
    three functions - finding files, including files and error reporting
    - into one. How it's better?
    Because its tons more efficient, requires less code from the end user
    and all the various other reasons i have stated before. Again we seem
    to have different priorities but reiterating them doesnt provide value
    for this mailinglist. So your points are taken, I will add them to the
    RFC. We will see if other people have an opinion and then someone
    might call for a vote.
    Now I also made it clear that its not about blindly silencing
    "errors" but there is a need to differentiate between different
    error causes. Of
    How you are going to differentiate? Your proposal only has one
    return value (null) which is conveniently coincides with return
    value that can be produced by include too by doing return;. You
    don't know why it failed, you don't even really know did it fail or
    not. You just know you got null in return.
    I stated the differences to include. As such I did not state that
    syntax errors should be handled differently, so in the case of a
    syntax error false would be returned and a warning raised.
    1) checking before adds overhead and opens issue with potential
    race conditions
    I don't think it's real use case - please show me one framework that
    uses plugin includes through include path while other processes are
    deleting their plugins randomly. I think you are trying to solve non-
    existing problem here. Caching/templating APIs usually know exactly
    where their files are and don't need to look for them in include path.
    I never claimed that the race condition is a common scenario. Do note
    that I always called this an edge case, both on this list an in the
    RFC. The performance overhead however is real, both from additional
    function calls as well as additional filesystem access.
    2) silencing the error and using track errors adds overhead and
    potential issues with custom error handlers
    Again, what frameworks need is to find the right file among variety
    of possibilities in include path and then include it. I think it can
    be well served by using existing "include" with addition of "find"
    API and there's no necessity for new language construct to serve one
    specific use case. In a month, some framework would have slightly
    different use case and you'd invent another packaged language
    construct for this?

    You are repeating yourself in the same email. You are not addressing
    2) so just leave it out on your reply.
    To address your comment about if I am going to invent another
    construct. I have as well as other framework developers brought up
    this limitation in PHP for a while. You might have also noticed that
    this construct aka hack has been around for a while. So I am not
    trying to patch up the issues I discovered yesterday, I am trying to
    find a solution for a problem that has been know since years. As a
    result I do not share your concern that tomorrow we will need yet
    another different "magic" method to handle includes.

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
  • Alban at Nov 10, 2009 at 9:41 pm

    Le Tue, 10 Nov 2009 21:56:47 +0100, Lukas Kahwe Smith a écrit :
    On 10.11.2009, at 21:31, Stanislav Malyshev wrote:

    ok .. so your objection to the RFC is solely because it introduces a
    new language construct?
    No, my objection is that it is not necessary to introduce a language
    construct, and the construct introduced is not the right one. If
    frameworks want to find out if file exists or get its name - we should
    give them API to do that. If they want just to silence the errors -
    they already have the construct to do that.

    They dont want to determine if a file exists. They want to be able to
    handle the case of a missing file being included differently than a
    syntax error. Since php core does not provide such features, the only
    way to do this is using the fopen() hack, iterating over the include
    path .. or I guess track errors with @. My proposal actually makes it
    possible to do what the frameworks need with less overhead. There is no
    way to do what these frameworks need inside userland without the above
    mentioned hacks. The fact that almost all frameworks are forced to use
    these hacks and quite a significant number of developers use frameworks
    (resulting in quite a number of apps end users install also using these
    frameworks) implies that we are not talking about an edge case here.

    Now I also made it clear that its not about blindly silencing "errors"
    but there is a need to differentiate between different error causes. Of
    course having to use @ for such a common use case is also not ideal. Its
    just that the error handling we provide internally isnt really able to
    handle this scenario well:

    1) checking before adds overhead and opens issue with potential race
    conditions
    2) silencing the error and using track errors adds overhead and
    potential issues with custom error handlers

    Anyways, lets see if there are other comments in the coming days. I
    think you have made your priorities clear. At least I understand them,
    but do not share them.

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
    Hi,

    I think if PHP throws exception instead of warning/error then this
    problem will not have existence reason :

    try
    {
    include 'file';

    // if we are sure about data sort in get_included_files, just do :

    $fullFileName = array_pop(get_included_files());

    // ...
    }
    catch(phpParseIncludeException $e)
    {
    // ...
    }
    catch(missingIncludeException $e)
    {
    // ...
    }
    catch(includeException $e)
    {
    // ...
    }

    regards,
    Alban Leroux
    seza@paradoxal.org
  • Lukas Kahwe Smith at Nov 10, 2009 at 9:59 pm

    On 10.11.2009, at 22:41, Alban wrote:

    I think if PHP throws exception instead of warning/error then this
    problem will not have existence reason :

    sure with exceptions we could provide more contextual information and
    also give a local way to handle the situation locally. that being said
    for now it was decided to only use exception for constructor errors in
    core php.

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
  • Christian Schneider at Nov 10, 2009 at 5:17 pm

    Lukas Kahwe Smith wrote:
    I have written an RFC for a more efficient solution to get rid of the
    common fopen() hack inside autoloaders:
    if ($fp = @fopen($file, 'r', true)) {
    fclose($fp);
    include $file;
    }

    Here is the gist of the proposal:
    In order to solve the above issues this RFC proposes the addition of a
    new construct/function for now called “autoload_include” for lack of a
    better name that largely behaves like the “include” does today with the
    following differences, that when the include failed because of a missing
    file no warning is raised and php null is returned.
    Alternatively include() could be extended to allow resources, so the
    above would turn info

    if ($fp = @fopen($file, 'r', true)) {
    include($fp);
    fclose($fp);
    }

    Pros: No new function name needed, works with all streams (e.g. phar?)
    Cons: fopen/fclose are still needed, determining real path not obvious
    Maybes: Any security implications? Don't think so but not sure.

    I like the general idea, just throwing in another option,
    - Chris
  • Stanislav Malyshev at Nov 10, 2009 at 6:17 pm
    Hi!
    Alternatively include() could be extended to allow resources, so the
    above would turn info

    if ($fp = @fopen($file, 'r', true)) {
    include($fp);
    fclose($fp);
    }
    This would break security distinction between file ops and include ops,
    when URLs are allowed for open but not include.

    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Rasmus Lerdorf at Nov 10, 2009 at 6:20 pm

    Stanislav Malyshev wrote:
    Hi!
    Alternatively include() could be extended to allow resources, so the
    above would turn info

    if ($fp = @fopen($file, 'r', true)) {
    include($fp);
    fclose($fp);
    }
    This would break security distinction between file ops and include ops,
    when URLs are allowed for open but not include.
    Yes, I was going to say, this sounds like a very bad idea security-wise.
    We'd be back to the local vs. remote resource identification problem.

    -Rasmus
  • Greg Beaver at Nov 10, 2009 at 7:57 pm

    Stanislav Malyshev wrote:
    Hi!
    Alternatively include() could be extended to allow resources, so the
    above would turn info

    if ($fp = @fopen($file, 'r', true)) {
    include($fp);
    fclose($fp);
    }
    This would break security distinction between file ops and include ops,
    when URLs are allowed for open but not include.
    Not really - the wrapper used to open the file pointer is stored in the
    resource, so we can just check it against the same restrictions we would
    for static urls. I think this idea deserves another look.

    Greg
  • Stanislav Malyshev at Nov 10, 2009 at 8:28 pm
    Hi!
    This would break security distinction between file ops and include ops,
    when URLs are allowed for open but not include.
    Additional thing - it probably would be a problem for bytecode caches,
    since they'd have to:
    a. watch all file opens, in case some of these will later be used for
    include
    b. somehow be able to get filename back from open stream to get the
    cached file.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Greg Beaver at Nov 11, 2009 at 12:24 am

    Stanislav Malyshev wrote:
    Hi!
    This would break security distinction between file ops and include ops,
    when URLs are allowed for open but not include.
    Additional thing - it probably would be a problem for bytecode caches,
    since they'd have to:
    a. watch all file opens, in case some of these will later be used for
    include
    b. somehow be able to get filename back from open stream to get the
    cached file.
    Hi again,

    A good point. Fortunately, most streams do store the filename in the
    stream struct, so this would still probably be possible in the majority
    of cases. If not available, the original requested filename is used
    (the one from the fopen call), so opcode caches probably could just use
    that.

    Greg
  • Stanislav Malyshev at Nov 11, 2009 at 12:37 am
    Hi!
    A good point. Fortunately, most streams do store the filename in the
    stream struct, so this would still probably be possible in the majority
    of cases. If not available, the original requested filename is used
    (the one from the fopen call), so opcode caches probably could just use
    that.
    The problem is, by then the stream will already be opened, i.e. extra
    filesystem call is done.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Greg Beaver at Nov 11, 2009 at 12:50 am

    Stanislav Malyshev wrote:
    Hi!
    A good point. Fortunately, most streams do store the filename in the
    stream struct, so this would still probably be possible in the majority
    of cases. If not available, the original requested filename is used
    (the one from the fopen call), so opcode caches probably could just use
    that.
    The problem is, by then the stream will already be opened, i.e. extra
    filesystem call is done.
    Hi,

    Yes, but let's not forget we're talking about making this:

    <?php
    if ($fp = @fopen($file, 'r', true)) {
    fclose($fp);
    include $file;
    }
    // 2 stats, fopen + include
    ?>

    into this:

    <?php

    if ($fp = @fopen($file, 'r', true)) {
    include($fp);
    fclose($fp);
    }
    // 1 stat, fopen
    ?>

    Of course 1 stat is worse than no stats. Perhaps better would be to introduce a function:

    if (can_include($file)) {
    include $file;
    }

    opcode caches could easily snag this, as we could provide a simple hook the way we do with stream_resolve_path(). That would actually make a 0-stat smart autoloader a possibility. Just in case it isn't obvious, can_include() would be the equivalent to an include_path search followed by is_readable(), which is essentially what the fopen() hack does now. can_include() would also remove the unnecessary opening of the file that fopen() performs.

    Greg
  • Stanislav Malyshev at Nov 11, 2009 at 1:20 am
    Hi!
    Yes, but let's not forget we're talking about making this:
    While with proper caching, it can be 0 filesystem accesses.
    if (can_include($file)) {
    include $file;
    }
    That's exactly what I was proposing - to have function to find file in
    include path and probably return the resulting filename (in case
    framework wants to keep it, or cache, or use it as a key or whatever).
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Lukas Kahwe Smith at Nov 11, 2009 at 7:27 am

    Perhaps better would be to introduce a function:

    if (can_include($file)) {
    include $file;
    }

    opcode caches could easily snag this, as we could provide a simple
    hook the way we do with stream_resolve_path(). That would actually
    make a 0-stat smart autoloader a possibility. Just in case it isn't
    obvious, can_include() would be the equivalent to an include_path
    search followed by is_readable(), which is essentially what the fopen
    () hack does now. can_include() would also remove the unnecessary
    opening of the file that fopen() performs.
    so you are suggesting that the byte code cache also cache file
    searches performed by this function. this is starting to sound more
    interesting from my pov.

    regards
    lukas
  • Richard Quadling at Nov 11, 2009 at 9:48 am
    2009/11/11 Lukas Kahwe Smith [snip]

    Would using a userland-based set_error_handler() be of use here?

    If, under normal circumstances, blind include() is what is used, then
    trapping the error when it fails would be when you could test for
    whatever it is you want to test for?

    Richard.



    --
    -----
    Richard Quadling
    "Standing on the shoulders of some very clever giants!"
    EE : http://www.experts-exchange.com/M_248814.html
    Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
    ZOPA : http://uk.zopa.com/member/RQuadling
  • Lukas Kahwe Smith at Nov 11, 2009 at 9:53 am

    On 11.11.2009, at 10:47, Richard Quadling wrote:

    2009/11/11 Lukas Kahwe Smith <mls@pooteeweet.org>:
    [snip]
    Would using a userland-based set_error_handler() be of use here?

    If, under normal circumstances, blind include() is what is used, then
    trapping the error when it fails would be when you could test for
    whatever it is you want to test for?

    Well this makes it impossible to handle the issue locally, which
    creates all sorts of issues when you just want to drop in a frameworks
    autoloader. It also means that you now globally handle such failures,
    where you do not know if in case the file is missing there will be
    additional logic locally to handle the failure. Furthermore unless you
    use track errors you would not be able to determine if the load failed
    because of a missing file or a syntax error.

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
  • Lukas Kahwe Smith at Nov 11, 2009 at 10:00 am

    On 11.11.2009, at 01:50, Greg Beaver wrote:

    if (can_include($file)) {
    include $file;
    }

    I am sure you focused on the technical aspects. Just wanted to say
    that for a name "can" is not ideal, because there is no gurantee that
    the file will not have syntax errors. As such something with "exists"
    is better (for example include_file_exists(), though also not
    ideal) .. Stas proposal of a "file_find()" is also good, but I think
    it would be nice to have "include" in the name.

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
  • Mikko Koppanen at Nov 11, 2009 at 10:44 am

    On Wed, Nov 11, 2009 at 10:00 AM, Lukas Kahwe Smith wrote:
    On 11.11.2009, at 01:50, Greg Beaver wrote:

    if (can_include($file)) {
    include $file;
    }

    I am sure you focused on the technical aspects. Just wanted to say that for
    a name "can" is not ideal, because there is no gurantee that the file will
    not have syntax errors. As such something with "exists" is better (for
    example include_file_exists(), though also not ideal) .. Stas proposal of a
    "file_find()" is also good, but I think it would be nice to have "include"
    in the name.
    Isn't this what stream_resolve_include_path does?


    --
    Mikko Koppanen
  • Lukas Kahwe Smith at Nov 11, 2009 at 11:47 am

    On 11.11.2009, at 11:44, Mikko Koppanen wrote:

    On Wed, Nov 11, 2009 at 10:00 AM, Lukas Kahwe Smith <mls@pooteeweet.org
    wrote:
    On 11.11.2009, at 01:50, Greg Beaver wrote:

    if (can_include($file)) {
    include $file;
    }

    I am sure you focused on the technical aspects. Just wanted to say
    that for
    a name "can" is not ideal, because there is no gurantee that the
    file will
    not have syntax errors. As such something with "exists" is better
    (for
    example include_file_exists(), though also not ideal) .. Stas
    proposal of a
    "file_find()" is also good, but I think it would be nice to have
    "include"
    in the name.
    Isn't this what stream_resolve_include_path does?
    it might .. the doc's are sort of unclear .. since fopen optionally
    checks the include path. then again the name of the function implies
    that it does a search in the include path. the name is a bit long ..
    but i like the use of "resolve".

    so a byte code cache should cache the resolution of the path thereby
    speeding up the subsequent call to include?

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
  • Greg Beaver at Nov 11, 2009 at 1:50 pm

    Lukas Kahwe Smith wrote:
    On 11.11.2009, at 11:44, Mikko Koppanen wrote:

    On Wed, Nov 11, 2009 at 10:00 AM, Lukas Kahwe Smith
    wrote:
    On 11.11.2009, at 01:50, Greg Beaver wrote:

    if (can_include($file)) {
    include $file;
    }

    I am sure you focused on the technical aspects. Just wanted to say
    that for
    a name "can" is not ideal, because there is no gurantee that the
    file will
    not have syntax errors. As such something with "exists" is better (for
    example include_file_exists(), though also not ideal) .. Stas
    proposal of a
    "file_find()" is also good, but I think it would be nice to have
    "include"
    in the name.
    Isn't this what stream_resolve_include_path does?
    it might .. the doc's are sort of unclear .. since fopen optionally
    checks the include path. then again the name of the function implies
    that it does a search in the include path. the name is a bit long ..
    but i like the use of "resolve".

    so a byte code cache should cache the resolution of the path thereby
    speeding up the subsequent call to include?
    stream_resolve_include_path() as currently constructed could not be
    intercepted, and is actually unable to process an include_path that
    contains streams. I'm guessing it was written long before PHP 5.3.
    This could be easily fixed by having stream_resolve_include_path call
    zend_resolve_path() instead of doing its own internal calculations.
    With these changes, an opcode cache could easily cache the results.

    As for your naming concerns, if we were to add an alias called
    is_includable() to stream_resolve_include_path(), that would be much
    clearer:

    if (is_includable($file)) {
    include $file;
    }

    The assumption here is that we are simply testing whether the file
    exists and whether php can actually read the file, not whether the file
    has syntax errors. A file with syntax errors is an exceptional
    situation, and should be handled by a clear fatal error, imo.

    Greg
  • Lukas Kahwe Smith at Nov 11, 2009 at 1:57 pm

    On 11.11.2009, at 14:50, Greg Beaver wrote:

    Lukas Kahwe Smith wrote:
    On 11.11.2009, at 11:44, Mikko Koppanen wrote:

    On Wed, Nov 11, 2009 at 10:00 AM, Lukas Kahwe Smith
    so a byte code cache should cache the resolution of the path thereby
    speeding up the subsequent call to include?
    stream_resolve_include_path() as currently constructed could not be
    intercepted, and is actually unable to process an include_path that
    contains streams. I'm guessing it was written long before PHP 5.3.
    This could be easily fixed by having stream_resolve_include_path call
    zend_resolve_path() instead of doing its own internal calculations.
    With these changes, an opcode cache could easily cache the results. ok.
    As for your naming concerns, if we were to add an alias called
    is_includable() to stream_resolve_include_path(), that would be much
    clearer:

    if (is_includable($file)) {
    include $file;
    }

    The assumption here is that we are simply testing whether the file
    exists and whether php can actually read the file, not whether the
    file
    Well I still maintain that is_includable() could imply for people that
    no error can occur. Just like when calling is_int() means that it
    really is an integer. so I still prefer "exists" or "resolve".
    has syntax errors. A file with syntax errors is an exceptional
    situation, and should be handled by a clear fatal error, imo.

    well the error raised for a syntax error or missing file would not
    change if we go in this direction.

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
  • Lukas Kahwe Smith at Nov 22, 2009 at 5:02 pm

    On 11.11.2009, at 14:50, Greg Beaver wrote:

    stream_resolve_include_path() as currently constructed could not be
    intercepted, and is actually unable to process an include_path that
    contains streams. I'm guessing it was written long before PHP 5.3.
    This could be easily fixed by having stream_resolve_include_path call
    zend_resolve_path() instead of doing its own internal calculations.
    With these changes, an opcode cache could easily cache the results.
    ok. sounds like something that should be done.
    As for your naming concerns, if we were to add an alias called
    is_includable() to stream_resolve_include_path(), that would be much
    clearer:

    if (is_includable($file)) {
    include $file;
    }

    The assumption here is that we are simply testing whether the file
    exists and whether php can actually read the file, not whether the file
    has syntax errors. A file with syntax errors is an exceptional
    situation, and should be handled by a clear fatal error, imo.

    Well for all I care it could remain with stream_resolve_include_path(), though I am not sure if we really need that "stream" namespace, then again its a function that will not be used a lot in daily coding, so I do not care either way.

    I have updated the current RFC accordingly:
    http://wiki.php.net/rfc/autoload_include

    So there are three approaches listed in the RFC:
    1) http://wiki.php.net/rfc/autoload_include#proposal
    add a new alternative to include, which works the same except that for missing files it returns null and on success it returns the file location (unless the file already returns something else explicitly)

    2) http://wiki.php.net/rfc/autoload_include#add_stream_support_to_includerequire
    add stream support to include/require

    3) http://wiki.php.net/rfc/autoload_include#add_function_to_resolve_the_include_path
    fix up stream_resolve_include_path() to support streams.

    I would like to call for a vote on the above. For 1) and 3) I invite everybody to optionally also submit a proposal for a name. Finally optionally include in your vote if would like to see this feature added to 5.3.2 or if it should wait for the next minor/major version update instead.

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
  • Lukas Kahwe Smith at Nov 22, 2009 at 5:57 pm

    On 22.11.2009, at 18:01, Lukas Kahwe Smith wrote:

    So there are three approaches listed in the RFC:
    1) http://wiki.php.net/rfc/autoload_include#proposal
    add a new alternative to include, which works the same except that for missing files it returns null and on success it returns the file location (unless the file already returns something else explicitly) -1
    2) http://wiki.php.net/rfc/autoload_include#add_stream_support_to_includerequire
    add stream support to include/require +1
    3) http://wiki.php.net/rfc/autoload_include#add_function_to_resolve_the_include_path
    fix up stream_resolve_include_path() to support streams.

    +1, resolve_include_path(), +1 for 5.3.2

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
  • Greg Beaver at Nov 23, 2009 at 4:38 am

    Lukas Kahwe Smith wrote:
    So there are three approaches listed in the RFC:
    1) http://wiki.php.net/rfc/autoload_include#proposal
    add a new alternative to include, which works the same except that for missing files it returns null and on success it returns the file location (unless the file already returns something else explicitly) -1
    2) http://wiki.php.net/rfc/autoload_include#add_stream_support_to_includerequire
    add stream support to include/require
    -1 (although it is worth noting that I think you may have missed my
    reply to Stas explaining how the problems he raised can be easily solved
    because of the way streams are implemented).
    3) http://wiki.php.net/rfc/autoload_include#add_function_to_resolve_the_include_path
    fix up stream_resolve_include_path() to support streams.
    +1 stream_resolve_include_path() - the name clearly shows it supports
    all streams.

    Greg
  • Greg Beaver at Nov 23, 2009 at 4:39 am

    Lukas Kahwe Smith wrote:
    Finally optionally include in your vote if would like to see this feature added to 5.3.2 or if it should wait for the next minor/major version update instead.
    +0 on version to include this in, sorry I forgot to include that in my vote.

    Greg
  • Lukas Kahwe Smith at Dec 7, 2009 at 1:44 pm

    On 22.11.2009, at 18:01, Lukas Kahwe Smith wrote:

    I have updated the current RFC accordingly:
    http://wiki.php.net/rfc/autoload_include

    So there are three approaches listed in the RFC:
    1) http://wiki.php.net/rfc/autoload_include#proposal
    add a new alternative to include, which works the same except that for missing files it returns null and on success it returns the file location (unless the file already returns something else explicitly)

    2) http://wiki.php.net/rfc/autoload_include#add_stream_support_to_includerequire
    add stream support to include/require

    3) http://wiki.php.net/rfc/autoload_include#add_function_to_resolve_the_include_path
    fix up stream_resolve_include_path() to support streams.

    I would like to call for a vote on the above. For 1) and 3) I invite everybody to optionally also submit a proposal for a name. Finally optionally include in your vote if would like to see this feature added to 5.3.2 or if it should wait for the next minor/major version update instead.

    I would like to raise this point once more. I am a bit surprised that nobody voted, but I got a lot of feedback from people about this proposal offlist when I first brought this to the list. Then again a lot of those people were not "core" developers. The fact remains however that a large number of frameworks rely on the @fopen() hack and so offering a better solution sooner rather than later seems like a very good idea.

    Then again, no vote essentially means sticking with the status quo aka stream_resolve_include_path() (which needs some additional love as the RFC states to really serve for what it was originally intended) when PHP6 comes out.

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
  • Stanislav Malyshev at Dec 9, 2009 at 12:04 am
    Hi!

    I think stream_resolve_include_path() should be changed to work through
    zend_resolve_path, in any case. Also, what is the reason it can't be in
    5.3 too?
    I'd like to both fix stream_resolve_include_path() and get it into 5.3,
    any objections to that?

    If that was done, only problem with using stream_resolve_include_path()
    is this manner:

    $realpath = stream_resolve_include_path($filename);

    if ($realpath && is_readable($realpath)) {
    include $realpath;
    } else {
    throw new Exception("What do you mean by $filename?");
    }

    This has disadvantage of using stat twice, but is_readable may be optional.
    This however does not solve the problem fully - since include could fail
    even though is_readable worked. But in that case I think it's OK for
    autoload to fail too - if there's a file in the path that exists, it's
    probably what you meant to include, so you probably don't want to try
    another one instead - you want it to fail.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Mikko Koppanen at Dec 23, 2009 at 2:57 pm

    On Wed, Dec 9, 2009 at 2:04 AM, Stanislav Malyshev wrote:
    Hi!

    I think stream_resolve_include_path() should be changed to work through
    zend_resolve_path, in any case. Also, what is the reason it can't be in 5.3
    too?
    I'd like to both fix stream_resolve_include_path() and get it into 5.3, any
    objections to that?
    Hi,

    this might work against PHP_5_3 and trunk:

    http://valokuva.org/patches/php/new/stream_resolve_include_path.txt



    --
    Mikko Koppanen
  • Ralph Schindler at Dec 28, 2009 at 11:25 pm
    Bump.

    I really think we need to think about this problem that Lukas has
    brought up.

    Now that the magic words have come up ('counting stat calls'), can we
    get someone to weight in on the possibility of both having some kind of
    include_path resolver in the 5.3 branch, and it's impact of stat calls
    in PHP both without an optimizer and with an optimizer?

    It seems like enough interest is here, as well as code, and those
    willing to contribute the functionality.. What about on the policy front?

    As you can tell, I am itching to see where this goes ;)

    -ralph

    Mikko Koppanen wrote:
    On Wed, Dec 9, 2009 at 2:04 AM, Stanislav Malyshev wrote:
    Hi!

    I think stream_resolve_include_path() should be changed to work through
    zend_resolve_path, in any case. Also, what is the reason it can't be in 5.3
    too?
    I'd like to both fix stream_resolve_include_path() and get it into 5.3, any
    objections to that?
    Hi,

    this might work against PHP_5_3 and trunk:

    http://valokuva.org/patches/php/new/stream_resolve_include_path.txt

  • Lukas Kahwe Smith at Jan 6, 2010 at 2:44 pm

    On 29.12.2009, at 00:25, Ralph Schindler wrote:

    Bump.

    I really think we need to think about this problem that Lukas has brought up.

    Now that the magic words have come up ('counting stat calls'), can we get someone to weight in on the possibility of both having some kind of include_path resolver in the 5.3 branch, and it's impact of stat calls in PHP both without an optimizer and with an optimizer?

    It seems like enough interest is here, as well as code, and those willing to contribute the functionality.. What about on the policy front?

    As you can tell, I am itching to see where this goes ;)

    just FYI:
    a tweaked stream_resolve_include_path() is scheduled for inclusion in PHP 5.3.3

    do note that the next PHP 5.3 release will be 5.3.2, so it will be a few months until we will see this feature in a stable release.

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org
  • Stanislav Malyshev at Nov 11, 2009 at 6:37 pm
    Hi!
    Isn't this what stream_resolve_include_path does?
    I wasn't even aware it was there (it being undocumented doesn't help a
    lot). And it is listed as PHP 6 only. I guess if we fix it to work
    correctly and backport to 5.3 (or even 5.2?) it may just work for
    frameworks.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Ralph Schindler at Nov 12, 2009 at 2:19 pm
    IIRC, Sara created this as a proof of concept to a reoccurring question
    of why filesystem functions don't have an include include_path argument.
    Many members argued (and for good merit), that any fs operations
    should not include the include_path. It was put into trunk and
    forgotten about, but ironically documented.

    Commentary:

    http://devzone.zend.com/node/view/id/1514#Heading7

    -ralph



    Stanislav Malyshev wrote:
    Hi!
    Isn't this what stream_resolve_include_path does?
    I wasn't even aware it was there (it being undocumented doesn't help a
    lot). And it is listed as PHP 6 only. I guess if we fix it to work
    correctly and backport to 5.3 (or even 5.2?) it may just work for
    frameworks.
  • Mark Skilbeck at Nov 10, 2009 at 5:41 pm

    Lukas Kahwe Smith wrote:
    Ahoi,

    I have written an RFC for a more efficient solution to get rid of the
    common fopen() hack inside autoloaders:
    if ($fp = @fopen($file, 'r', true)) {
    fclose($fp);
    include $file;
    }

    Here is the gist of the proposal:
    In order to solve the above issues this RFC proposes the addition of a
    new construct/function for now called “autoload_include” for lack of a
    better name that largely behaves like the “include” does today with the
    following differences, that when the include failed because of a missing
    file no warning is raised and php null is returned.

    Further details can be found on the wiki:
    http://wiki.php.net/rfc/autoload_include

    As stated in the RFC, I am not happy with the name "autoload_include".
    Suggestions welcome!

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org

    What's the problem with file_exists() ?
  • Lukas Kahwe Smith at Nov 10, 2009 at 5:53 pm

    On 10.11.2009, at 18:40, Mark Skilbeck wrote:
    What's the problem with file_exists() ?
    i have explained this in the RFC. for one it does not support the
    include path setting. furthermore this does not solve the race
    condition and requires more FS operations than my proposal would.

    regards
    Lukas
  • Igor Feghali at Nov 10, 2009 at 6:37 pm

    As stated in the RFC, I am not happy with the name "autoload_include".
    Suggestions welcome!
    That reminds me of the set theory...

    how about:

    contain $file;
    or
    superset $file;

    there are also the not so original (as found in many other languages)
    keywords "import" / "load".

    Best,
    ~IF.
  • Ralph Schindler at Nov 12, 2009 at 2:27 pm
    There is one key piece of information to keep in mind about this
    proposal. This is based on the assumption that all autoloaders need to
    do this type of include_path check. I (now) feel this is questionable
    concerning that particular use case.

    The best practice should be to only have autoloaders for a specific
    namespace, this would mostly solve the "is it there?" type of
    fopen/include_path check.

    If NamespaceA registers an autoloader for itself, it should not try to
    resolve and load files from other Namespaces, for example NamespaceB.
    This idea is partially taken care of in the proposed SplClassLoader ..

    http://gist.github.com/221634

    .. assuming the above best practice, a namespcae should know whether or
    not to try to include something inside it's own namespace, and if
    something is not there, an E_FATAL (or potentially an exception) is the
    best option when include does not work. I also have a question as to
    how the argument: throw=true comes into play in the current
    spl_autoload_register (does it affect this proposal too?)

    http://github.com/php/php-src/blob/PHP_5_3_1/ext/spl/php_spl.c#L422

    ON THE OTHER HAND, I think it is important that we should be able to
    check for the existence of a relative to include_path location
    regardless of autoloading consequences, and that is what sara attempted
    with stream_resolve_include_path, even though I'm not fond of the name.

    Regards,
    Ralph Schindler


    Lukas Kahwe Smith wrote:
    Ahoi,

    I have written an RFC for a more efficient solution to get rid of the
    common fopen() hack inside autoloaders:
    if ($fp = @fopen($file, 'r', true)) {
    fclose($fp);
    include $file;
    }

    Here is the gist of the proposal:
    In order to solve the above issues this RFC proposes the addition of a
    new construct/function for now called “autoload_include” for lack of a
    better name that largely behaves like the “include” does today with the
    following differences, that when the include failed because of a missing
    file no warning is raised and php null is returned.

    Further details can be found on the wiki:
    http://wiki.php.net/rfc/autoload_include

    As stated in the RFC, I am not happy with the name "autoload_include".
    Suggestions welcome!

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org


  • Lukas Kahwe Smith at Nov 12, 2009 at 3:41 pm

    On 12.11.2009, at 15:27, Ralph Schindler wrote:

    There is one key piece of information to keep in mind about this
    proposal. This is based on the assumption that all autoloaders need
    to do this type of include_path check. I (now) feel this is
    questionable concerning that particular use case.

    The best practice should be to only have autoloaders for a specific
    namespace, this would mostly solve the "is it there?" type of fopen/
    include_path check.

    If NamespaceA registers an autoloader for itself, it should not try
    to resolve and load files from other Namespaces, for example
    NamespaceB. This idea is partially taken care of in the proposed
    SplClassLoader ..

    http://gist.github.com/221634

    .. assuming the above best practice, a namespcae should know whether
    or not to try to include something inside it's own namespace, and if
    something is not there, an E_FATAL (or potentially an exception) is
    the best option when include does not work. I also have a question
    as to how the argument: throw=true comes into play in the current
    spl_autoload_register (does it affect this proposal too?)

    http://github.com/php/php-src/blob/PHP_5_3_1/ext/spl/php_spl.c#L422

    ON THE OTHER HAND, I think it is important that we should be able to
    check for the existence of a relative to include_path location
    regardless of autoloading consequences, and that is what sara
    attempted with stream_resolve_include_path, even though I'm not fond
    of the name.

    your argument has some merit, however i think that the use case should
    still be supported.

    well even inside your own namespace it can be tricky to know the file
    name. for example in MDB2 i allowed the creation of modules. these
    could either be generic or rdbms dependent. since i did not want to
    have to maintain some registry that knows all modules (especially
    since modules can be added by users), i had to search for the right
    class name by seeing which file was available (either a directory with
    the module name and rdbms drivers as the php files .. or a generic php
    file). there might be other similar use cases, like having to deal
    with legacy code.

    regards,
    Lukas Kahwe Smith
    mls@pooteeweet.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedNov 10, '09 at 4:45p
activeJan 6, '10 at 2:44p
posts47
users12
websitephp.net

People

Translate

site design / logo © 2022 Grokbase