FAQ
Hi,

Please look into patch that implements __autoload() support for namespaces.
The patch touches not only ZE but also SPL.

In the following code we cannot exactly know if "Exception" class is from
current namespace or it is an internal PHP class.

<?php
namespace Foo;
throw new Exception;

In this case PHP first looks for Foo::Exception and only then for internal
Exception, but the first lookup may call __autoload (or corresponding SPL
functions) and it can emit error or throw exception.

The patch provides an additional boolean argument to __autoload() that say
if class is really required. In case if it false, user code shouldn't emit
errors or throw exceptions.

I am going to commit the patch on Wednesday.

It is the last semantic patch for namespaces we have.
After its commit we are going to look into syntax problems (namespace or
package, brackets, import or using, ...).

Thanks. Dmitry.

Search Discussions

  • Stanislav Malyshev at Aug 27, 2007 at 5:49 pm

    <?php
    namespace Foo;
    throw new Exception;

    In this case PHP first looks for Foo::Exception and only then for internal
    Exception, but the first lookup may call __autoload (or corresponding SPL
    functions) and it can emit error or throw exception.

    The patch provides an additional boolean argument to __autoload() that say
    if class is really required. In case if it false, user code shouldn't emit
    errors or throw exceptions.
    There's two problems here:
    1. On each access to internal class, like Exception, SPL classes,
    DateTime, reflection classes, etc. - we'd have call to autoload and
    subsequent disk access, maybe more than one if we have include path.
    Performance of it would be awful.
    2. All libraries having autoloaders would have to rewrite them to
    support the new mode.

    I would propose different solution. When we have unresolved unqualified
    name, we do the following:
    1. Check if we already know such class in namespace at compile-time. If
    so, it's resolved.
    2. If not, will be resolved at run-time.
    3. At run-time, check if we know such class in namespace now. If yes,
    it's resolved.
    4. If not, check if we know internal class with such name. If yes, it's
    resolved to internal class.
    5. If not, try to autoload this class. If autoloading fails, it's the
    undefined class error.

    This rule is a bit more complex, but allows to resolve common cases
    without extra filesystem accesses and allows to keep autoloader without
    modification.

    Comments?
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Dmitry Stogov at Aug 27, 2007 at 6:08 pm
    This is an implementation of Stas idea.

    1) Look for existent class in current namespace
    2) Look for existent internal class
    3) Try to autoload class from current namespace

    Thanks. Dmitry.
    -----Original Message-----
    From: Stanislav Malyshev
    Sent: Monday, August 27, 2007 9:49 PM
    To: Dmitry Stogov
    Cc: 'PHP Internals List'
    Subject: Re: [PHP-DEV] Namespaces and __autoload()

    <?php
    namespace Foo;
    throw new Exception;

    In this case PHP first looks for Foo::Exception and only then for
    internal Exception, but the first lookup may call __autoload (or
    corresponding SPL
    functions) and it can emit error or throw exception.

    The patch provides an additional boolean argument to
    __autoload() that
    say if class is really required. In case if it false, user code
    shouldn't emit errors or throw exceptions.
    There's two problems here:
    1. On each access to internal class, like Exception, SPL classes,
    DateTime, reflection classes, etc. - we'd have call to autoload and
    subsequent disk access, maybe more than one if we have include path.
    Performance of it would be awful.
    2. All libraries having autoloaders would have to rewrite them to
    support the new mode.

    I would propose different solution. When we have unresolved
    unqualified
    name, we do the following:
    1. Check if we already know such class in namespace at
    compile-time. If
    so, it's resolved.
    2. If not, will be resolved at run-time.
    3. At run-time, check if we know such class in namespace now. If yes,
    it's resolved.
    4. If not, check if we know internal class with such name. If
    yes, it's
    resolved to internal class.
    5. If not, try to autoload this class. If autoloading fails, it's the
    undefined class error.

    This rule is a bit more complex, but allows to resolve common cases
    without extra filesystem accesses and allows to keep
    autoloader without
    modification.

    Comments?
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Jochem Maas at Aug 27, 2007 at 9:45 pm

    Dmitry Stogov wrote:
    This is an implementation of Stas idea.

    1) Look for existent class in current namespace
    2) Look for existent internal class
    3) Try to autoload class from current namespace
    both ways have a wtf factor in that class with names
    matching 'internal' class names behave differently.

    afaict you would not be able to autoload class Exception
    from within namespace Foo in the example below.

    currently one cannot create classes named the same as
    'internal' classes ... obviously.

    I would consider making internal class names illegal
    in namespaces. this would be consistent simple and clear.

    also I don't see what would be gained from being allowed
    to do:

    <?php

    namespace Foo;
    class Exception extends Exception {};

    I assume all the SPL stuff wont be moved into into own
    namespace straight away with regard to BC, would that be correct?

    rgds,
    Jochem

    Thanks. Dmitry.
    -----Original Message-----
    From: Stanislav Malyshev
    Sent: Monday, August 27, 2007 9:49 PM
    To: Dmitry Stogov
    Cc: 'PHP Internals List'
    Subject: Re: [PHP-DEV] Namespaces and __autoload()

    <?php
    namespace Foo;
    throw new Exception;

    In this case PHP first looks for Foo::Exception and only then for
    internal Exception, but the first lookup may call __autoload (or
    corresponding SPL
    functions) and it can emit error or throw exception.

    The patch provides an additional boolean argument to
    __autoload() that
    say if class is really required. In case if it false, user code
    shouldn't emit errors or throw exceptions.
    There's two problems here:
    1. On each access to internal class, like Exception, SPL classes,
    DateTime, reflection classes, etc. - we'd have call to autoload and
    subsequent disk access, maybe more than one if we have include path.
    Performance of it would be awful.
    2. All libraries having autoloaders would have to rewrite them to
    support the new mode.

    I would propose different solution. When we have unresolved
    unqualified
    name, we do the following:
    1. Check if we already know such class in namespace at
    compile-time. If
    so, it's resolved.
    2. If not, will be resolved at run-time.
    3. At run-time, check if we know such class in namespace now. If yes,
    it's resolved.
    4. If not, check if we know internal class with such name. If
    yes, it's
    resolved to internal class.
    5. If not, try to autoload this class. If autoloading fails, it's the
    undefined class error.

    This rule is a bit more complex, but allows to resolve common cases
    without extra filesystem accesses and allows to keep
    autoloader without
    modification.

    Comments?
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Stanislav Malyshev at Aug 27, 2007 at 9:49 pm

    afaict you would not be able to autoload class Exception
    from within namespace Foo in the example below.
    I think if you want it to work you don't have to autoload it/
    I would consider making internal class names illegal
    in namespaces. this would be consistent simple and clear.
    It's one of the options, but I'm not sure it's the best one. Opinions
    welcome.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Christian Schneider at Aug 27, 2007 at 10:06 pm

    Stanislav Malyshev wrote:
    I would consider making internal class names illegal
    in namespaces. this would be consistent simple and clear.
    It's one of the options, but I'm not sure it's the best one. Opinions
    welcome.
    I don't think that's a good solution because that kind of defeats the
    reason we want to introduce namespaces in the first place: I can name my
    classes without having to be afraid of a name clash later on when PHP
    adds new classes.

    Unless the restriction only applies to the current (global) internal
    classes and all new classes are going to be introduced within a PHP
    reserved namespace (e.g. PHP::Date instead of Date or the like) while
    not adding more names to the list of illegal names. And even then I
    would prefer no restriction and give the programmers full freedom of
    naming within their namespace.

    - Chris
  • Gregory Beaver at Aug 27, 2007 at 10:28 pm

    Jochem Maas wrote:
    Dmitry Stogov wrote:
    This is an implementation of Stas idea.

    1) Look for existent class in current namespace
    2) Look for existent internal class
    3) Try to autoload class from current namespace
    both ways have a wtf factor in that class with names
    matching 'internal' class names behave differently.

    afaict you would not be able to autoload class Exception
    from within namespace Foo in the example below.

    currently one cannot create classes named the same as
    'internal' classes ... obviously.

    I would consider making internal class names illegal
    in namespaces. this would be consistent simple and clear.
    If this happens, namespaces will be useless, and we'll be forced to use
    _ in all classnames again to avoid potential conflicts with internal
    classes.
    also I don't see what would be gained from being allowed
    to do:

    <?php

    namespace Foo;
    class Exception extends Exception {};
    That looks awful :).

    This should be:

    class Exception extends ::Exception {}

    Anything else does not strike me as good coding practice.

    Greg
  • Gregory Beaver at Aug 27, 2007 at 10:34 pm

    Stanislav Malyshev wrote:
    <?php
    namespace Foo;
    throw new Exception;

    In this case PHP first looks for Foo::Exception and only then for
    internal
    Exception, but the first lookup may call __autoload (or corresponding SPL
    functions) and it can emit error or throw exception.

    The patch provides an additional boolean argument to __autoload() that
    say
    if class is really required. In case if it false, user code shouldn't
    emit
    errors or throw exceptions.
    There's two problems here:
    1. On each access to internal class, like Exception, SPL classes,
    DateTime, reflection classes, etc. - we'd have call to autoload and
    subsequent disk access, maybe more than one if we have include path.
    Performance of it would be awful.
    This is a problem, agreed.
    2. All libraries having autoloaders would have to rewrite them to
    support the new mode.
    This is not an issue - won't they have to support
    Class::Names::Like::This anyways? Backwards compatibility has already
    been broken.
    I would propose different solution. When we have unresolved unqualified
    name, we do the following:
    1. Check if we already know such class in namespace at compile-time. If
    so, it's resolved.
    2. If not, will be resolved at run-time.
    3. At run-time, check if we know such class in namespace now. If yes,
    it's resolved.
    4. If not, check if we know internal class with such name. If yes, it's
    resolved to internal class.
    5. If not, try to autoload this class. If autoloading fails, it's the
    undefined class error.
    The problem is that with this autoload technique this code now throws an
    Exception rather than a Foo::Exception:

    Foo/Exception.php:
    <?php
    namespace Foo;
    class Exception extends ::Exception {}
    ?>

    Foo/Something.php:
    <?php
    namespace Foo;
    function __autoload($class)
    {
    include str_replace('::', '/', $class) . '.php';
    }

    class Something
    {
    function __construct($param)
    {
    if ($param == 3) {
    throw new Exception('oops');
    }
    }
    }
    $a = new Something(3);
    ?>

    This would mean that all naming conflicts with internal classes must
    have a different import or be fully qualified.

    However, I wonder if using an import would be a clever way to get around
    the problem?

    Foo/Something.php:
    <?php
    namespace Foo;
    import Foo::Exception;
    function __autoload($class)
    {
    include str_replace('::', '/', $class) . '.php';
    }

    class Something
    {
    function __construct($param)
    {
    if ($param == 3) {
    throw new Exception('oops');
    }
    }
    }
    $a = new Something(3);
    ?>

    As I understand it, this would make the file act as if we had written it
    like:

    Foo/Something.php:
    <?php
    function __autoload($class)
    {
    include str_replace('::', '/', $class) . '.php';
    }

    class Foo::Something
    {
    function __construct($param)
    {
    if ($param == 3) {
    throw new Foo::Exception('oops');
    }
    }
    }
    $a = new Foo::Something(3);
    ?>

    If this is indeed the case, then it would satisfy my concerns with the
    patch and would simply be up to the documentation team to document this
    gotcha.

    Greg
  • Stanislav Malyshev at Aug 27, 2007 at 10:42 pm

    The problem is that with this autoload technique this code now throws an
    Exception rather than a Foo::Exception:
    Yep, unless you do require 'Foo/Exception.php'. Yes, I know it's not as
    nice as it might be. But the alternative is either use :: always or say
    goodbye to performance.
    However, I wonder if using an import would be a clever way to get around
    the problem?
    It would solve the issue too, of course.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • David Zülke at Aug 28, 2007 at 12:14 pm
    Why don't we add an optional second argument to __autoload() that
    receives the fully qualified namespace name of the class that should
    be autoloaded? That doesn't break BC and it prevents conflicts.


    David


    Am 27.08.2007 um 19:49 schrieb Stanislav Malyshev:
    <?php
    namespace Foo;
    throw new Exception;
    In this case PHP first looks for Foo::Exception and only then for
    internal
    Exception, but the first lookup may call __autoload (or
    corresponding SPL
    functions) and it can emit error or throw exception.
    The patch provides an additional boolean argument to __autoload()
    that say
    if class is really required. In case if it false, user code
    shouldn't emit
    errors or throw exceptions.
    There's two problems here:
    1. On each access to internal class, like Exception, SPL classes,
    DateTime, reflection classes, etc. - we'd have call to autoload and
    subsequent disk access, maybe more than one if we have include
    path. Performance of it would be awful.
    2. All libraries having autoloaders would have to rewrite them to
    support the new mode.

    I would propose different solution. When we have unresolved
    unqualified name, we do the following:
    1. Check if we already know such class in namespace at compile-
    time. If so, it's resolved.
    2. If not, will be resolved at run-time.
    3. At run-time, check if we know such class in namespace now. If
    yes, it's resolved.
    4. If not, check if we know internal class with such name. If yes,
    it's resolved to internal class.
    5. If not, try to autoload this class. If autoloading fails, it's
    the undefined class error.

    This rule is a bit more complex, but allows to resolve common cases
    without extra filesystem accesses and allows to keep autoloader
    without modification.

    Comments?
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Stanislav Malyshev at Aug 28, 2007 at 4:31 pm

    Why don't we add an optional second argument to __autoload() that
    receives the fully qualified namespace name of the class that should be
    autoloaded? That doesn't break BC and it prevents conflicts.
    The first argument already receives that, why would you need the second one?
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Derick Rethans at Aug 28, 2007 at 7:43 am

    On Mon, 27 Aug 2007, Dmitry Stogov wrote:

    In this case PHP first looks for Foo::Exception and only then for internal
    Exception, but the first lookup may call __autoload (or corresponding SPL
    functions) and it can emit error or throw exception.

    The patch provides an additional boolean argument to __autoload() that say
    if class is really required. In case if it false, user code shouldn't emit
    errors or throw exceptions.
    It looks like this is going to break BC. Are current autoload functions
    guaranteed to work with the new implementation?

    Derick
  • Dmitry Stogov at Aug 28, 2007 at 8:17 am
    Existing __autoload() will work fine with code without namespaces.

    Dmitry.
    -----Original Message-----
    From: Derick Rethans
    Sent: Tuesday, August 28, 2007 11:44 AM
    To: Dmitry Stogov
    Cc: 'PHP Internals List'
    Subject: Re: [PHP-DEV] Namespaces and __autoload()

    On Mon, 27 Aug 2007, Dmitry Stogov wrote:

    In this case PHP first looks for Foo::Exception and only then for
    internal Exception, but the first lookup may call __autoload (or
    corresponding SPL
    functions) and it can emit error or throw exception.

    The patch provides an additional boolean argument to
    __autoload() that
    say if class is really required. In case if it false, user code
    shouldn't emit errors or throw exceptions.
    It looks like this is going to break BC. Are current autoload
    functions
    guaranteed to work with the new implementation?

    Derick

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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • LAUPRETRE François (P) at Sep 7, 2007 at 3:20 pm
    Hi,
    From: Dmitry Stogov

    The patch provides an additional boolean argument to
    __autoload() that say if class is really required. In case if
    it false, user code shouldn't emit errors or throw exceptions.
    Actually, an autoload handler should never emit errors or throw exceptions. With handlers registered through SPL, it is already the case. When using an __autoload() functions, raising an error when a symbol is not found is useless because we know that the PHP interpreter will do it. So, I propose to have PHP ignore any error or exception raised from autoload handlers. This would make the additional argument useless.

    Actually, I also wanted to add a second argument to autoload handlers. It would give the type of the symbol we are looking for. Today, we are unable to know if we are searching for a class or an interface. So, an autoload handler like PHK's has to try both. It is not very important because most existing autoload handlers are so primitive (generally filename-based) that they treat both the same way. But, in the future, if we extend autoloading to functions and constants, we will need this argument. I cannot work on that now but, as you are considering modifying the autoload handler arguments, I thought you could be interested.

    Regards

    Francois
  • Stanislav Malyshev at Sep 7, 2007 at 11:50 pm

    Actually, an autoload handler should never emit errors or throw
    exceptions. With handlers registered through SPL, it is already the
    case. When using an __autoload() functions, raising an error when a
    symbol is not found is useless because we know that the PHP
    interpreter will do it. So, I propose to have PHP ignore any error or
    This is a good point - raising errors in chained autoloader makes little
    sense since next one in chain might be able to load the class. However,
    I am still concerned about the performance impact - exhausting all
    autoloading opportunities might be not cheap in big application, and it
    would be not nice if people just using something like $foo = new
    DateTime() would lose a lot of performance on it. I strive for "if you
    don't use it, you don't pay for it" approach - i.e. if you don't have
    own DateTime class, you shouldn't have to pay for the possibility of
    having one.
    interface. So, an autoload handler like PHK's has to try both. It is
    What do you mean by "try both"? Could you explain a bit more on that?
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Marcus Boerger at Sep 10, 2007 at 12:34 pm
    Hello Stanislav,

    Saturday, September 8, 2007, 1:50:24 AM, you wrote:
    Actually, an autoload handler should never emit errors or throw
    exceptions. With handlers registered through SPL, it is already the
    case. When using an __autoload() functions, raising an error when a
    symbol is not found is useless because we know that the PHP
    interpreter will do it. So, I propose to have PHP ignore any error or
    This is a good point - raising errors in chained autoloader makes little
    sense since next one in chain might be able to load the class. However,
    I am still concerned about the performance impact - exhausting all
    autoloading opportunities might be not cheap in big application, and it
    would be not nice if people just using something like $foo = new
    DateTime() would lose a lot of performance on it. I strive for "if you
    don't use it, you don't pay for it" approach - i.e. if you don't have
    own DateTime class, you shouldn't have to pay for the possibility of
    having one.
    interface. So, an autoload handler like PHK's has to try both. It is
    What do you mean by "try both"? Could you explain a bit more on that?
    I guess the point is that ppl might want to have interfaces use different
    approach than they want class to. For instance classes get filenames with
    just the classname followed by '.php' while interfaces might get a prefix
    'i_' or a different extension like '.inc'.

    Best regards,
    Marcus
  • Stanislav Malyshev at Sep 10, 2007 at 4:48 pm

    I guess the point is that ppl might want to have interfaces use different
    approach than they want class to. For instance classes get filenames with
    just the classname followed by '.php' while interfaces might get a prefix
    'i_' or a different extension like '.inc'.
    Well, since now autoloader doesn't have this info, I presume nobody
    actually does it now. I don't see a big benefit in enabling this, either.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Marcus Boerger at Sep 10, 2007 at 4:52 pm
    Hello Stanislav,

    me neither, I just wanted to clarify :-)

    marcus

    Monday, September 10, 2007, 6:48:14 PM, you wrote:
    I guess the point is that ppl might want to have interfaces use different
    approach than they want class to. For instance classes get filenames with
    just the classname followed by '.php' while interfaces might get a prefix
    'i_' or a different extension like '.inc'.
    Well, since now autoloader doesn't have this info, I presume nobody
    actually does it now. I don't see a big benefit in enabling this, either.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com



    Best regards,
    Marcus
  • LAUPRETRE François (P) at Sep 12, 2007 at 10:39 am

    From: Stanislav Malyshev

    This is a good point - raising errors in chained autoloader
    makes little
    sense since next one in chain might be able to load the
    class. However,
    I am still concerned about the performance impact - exhausting all
    autoloading opportunities might be not cheap in big
    application, and it
    would be not nice if people just using something like $foo = new
    DateTime() would lose a lot of performance on it. I strive
    for "if you
    don't use it, you don't pay for it" approach - i.e. if you don't have
    own DateTime class, you shouldn't have to pay for the possibility of
    having one.
    interface. So, an autoload handler like PHK's has to try both. It is
    What do you mean by "try both"? Could you explain a bit more on that?
    Yes. PHK's autoload handler is not filename-based. It works as a (poor man's :) runtime linker, with a symbol map. In this map, interfaces and classes have different symbol types. Today, when this handler receives a request, it cannot know if it should look for an interface or a class. So, it has to search both in turn.

    Please consider that filename-based autoload handlers are just a primitive implementation. If you consider only this family of handlers, that's right: getting the symbol type is not very important. But, with smarter map-based autoload handlers, it becomes very interesting to extend the feature to functions and, there, providing the symbol type along with the requested value becomes mandatory.

    Francois
  • Paweł Stradomski at Sep 12, 2007 at 12:32 pm

    W liście LAUPRETRE François z dnia środa, 12 września 2007 12:38:

    What do you mean by "try both"? Could you explain a bit more on that?
    Yes. PHK's autoload handler is not filename-based. It works as a (poor
    man's :) runtime linker, with a symbol map. In this map, interfaces and
    classes have different symbol types. Today, when this handler receives a
    request, it cannot know if it should look for an interface or a class. So,
    it has to search both in turn.

    Please consider that filename-based autoload handlers are just a primitive
    implementation. If you consider only this family of handlers, that's right:
    getting the symbol type is not very important. But, with smarter map-based
    autoload handlers, it becomes very interesting to extend the feature to
    functions and, there, providing the symbol type along with the requested
    value becomes mandatory.
    But how can interpreter know if it's looking for class or interface? There are
    obvious cases (class X implements Y, class A extends B, interface A extends
    B), but what with following language construct:

    function doSomething (Service s) {...}

    PHP tries to autoload type Service, but it can't know if it's looking for
    interface or class. Both are possible.

    --
    Paweł Stradomski
  • Stut at Sep 12, 2007 at 1:02 pm

    Paweł Stradomski wrote:
    W liście LAUPRETRE François z dnia środa, 12 września 2007 12:38:
    What do you mean by "try both"? Could you explain a bit more on that?
    Yes. PHK's autoload handler is not filename-based. It works as a (poor
    man's :) runtime linker, with a symbol map. In this map, interfaces and
    classes have different symbol types. Today, when this handler receives a
    request, it cannot know if it should look for an interface or a class. So,
    it has to search both in turn.

    Please consider that filename-based autoload handlers are just a primitive
    implementation. If you consider only this family of handlers, that's right:
    getting the symbol type is not very important. But, with smarter map-based
    autoload handlers, it becomes very interesting to extend the feature to
    functions and, there, providing the symbol type along with the requested
    value becomes mandatory.
    But how can interpreter know if it's looking for class or interface? There are
    obvious cases (class X implements Y, class A extends B, interface A extends
    B), but what with following language construct:

    function doSomething (Service s) {...}

    PHP tries to autoload type Service, but it can't know if it's looking for
    interface or class. Both are possible.
    This would need to come from the user implementation of __autoload
    through naming conventions or a lookup table. PHP does not get involved
    with resolving a type to a filename, and rightly so.

    -Stut
  • LAUPRETRE François (P) at Sep 12, 2007 at 1:50 pm

    From: Stut

    This would need to come from the user implementation of __autoload
    through naming conventions or a lookup table. PHP does not
    get involved
    with resolving a type to a filename, and rightly so.
    The question is not to have PHP get involved in the symbol to filename correspondance.

    I have a lookup table, but the requested type must come from the interpreter context and, if the autoload handler does not get it, it cannot know what type to look for in its lookup table. Unfortunately, even if not very common, a function and a class can have the same name. In this case, there will be two entries in the lookup table. If I don't know which type is requested, I can only search all known types. Maybe it would be enough but it wouldn't be elegant nor efficient, especially if we extend the mechanism to functions and constants.

    Francois
  • Stut at Sep 12, 2007 at 2:01 pm

    LAUPRETRE François (P) wrote:
    From: Stut

    This would need to come from the user implementation of __autoload
    through naming conventions or a lookup table. PHP does not
    get involved
    with resolving a type to a filename, and rightly so.
    The question is not to have PHP get involved in the symbol to filename correspondance.

    I have a lookup table, but the requested type must come from the interpreter context and, if the autoload handler does not get it, it cannot know what type to look for in its lookup table. Unfortunately, even if not very common, a function and a class can have the same name. In this case, there will be two entries in the lookup table. If I don't know which type is requested, I can only search all known types. Maybe it would be enough but it wouldn't be elegant nor efficient, especially if we extend the mechanism to functions and constants.
    I agree that if the autoload mechanism were extended to functions and
    constants (which I am opposed to, not that anyone will care) there would
    need to be a type provided to __autoload so it knew what it was looking
    for. However, this surely doesn't apply to classes and interfaces since
    the interpreter has no way of knowing and no reason to care what a
    particular symbol is since the two are interchangeable.

    -Stut
  • Paweł Stradomski at Sep 12, 2007 at 2:14 pm

    W liście Stut z dnia środa, 12 września 2007 15:59:
    LAUPRETRE François (P) wrote:
    From: Stut

    This would need to come from the user implementation of __autoload
    through naming conventions or a lookup table. PHP does not
    get involved
    with resolving a type to a filename, and rightly so.
    The question is not to have PHP get involved in the symbol to filename
    correspondance.

    I have a lookup table, but the requested type must come from the
    interpreter context and, if the autoload handler does not get it, it
    cannot know what type to look for in its lookup table. Unfortunately,
    even if not very common, a function and a class can have the same name.
    In this case, there will be two entries in the lookup table. If I don't
    know which type is requested, I can only search all known types. Maybe it
    would be enough but it wouldn't be elegant nor efficient, especially if
    we extend the mechanism to functions and constants.
    I agree that if the autoload mechanism were extended to functions and
    constants (which I am opposed to, not that anyone will care) there would
    need to be a type provided to __autoload so it knew what it was looking
    for. However, this surely doesn't apply to classes and interfaces since
    the interpreter has no way of knowing and no reason to care what a
    particular symbol is since the two are interchangeable.
    But is that flag really needed? If the code has some naming rules, then those
    can be used to determine what we're looking for - for example:
    something - a function
    SOMETHING - a constant
    Something - a class
    ISomething - an interface (although distinguishing between classes and
    interfaces is not strictly necessary as those are quite similar).

    So if such distinction is necessary, it can be coded for specific project,
    using such rules as a hint or as strict rule, depending on needs.

    --
    Paweł Stradomski
  • Stanislav Malyshev at Sep 12, 2007 at 4:50 pm

    function doSomething (Service s) {...}

    PHP tries to autoload type Service, but it can't know if it's looking
    Actually, in this case (and in any case where type of existing object is
    checked) autoloading is unnecessary (and it's a bug if it happens) since
    if the type Service is not loaded, there can be no objects of this type,
    thus we can decide the question of "is object s of type Service" without
    loading anything - the answer would be "no".

    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Paweł Stradomski at Sep 12, 2007 at 5:29 pm

    W liście Stanislav Malyshev z dnia środa, 12 września 2007:
    function doSomething (Service s) {...}

    PHP tries to autoload type Service, but it can't know if it's looking
    Actually, in this case (and in any case where type of existing object is
    checked) autoloading is unnecessary (and it's a bug if it happens) since
    if the type Service is not loaded, there can be no objects of this type,
    thus we can decide the question of "is object s of type Service" without
    loading anything - the answer would be "no".
    All right, seems it was fixed in the meantime -
    http://bugs.php.net/bug.php?id=39003

    --
    Paweł Stradomski
  • LAUPRETRE François (P) at Sep 12, 2007 at 1:39 pm

    From: Pawel Stradomski

    B), but what with following language construct:

    function doSomething (Service s) {...}

    PHP tries to autoload type Service, but it can't know if it's
    looking for interface or class. Both are possible.
    Correct. I didn't consider this case because I didn't know this syntax for interfaces.

    To include this case, we can consider that, instead of a 'type' value, the __autoload
    handler receives a bit mask of the four possible types that can be requested : classes,
    interfaces, functions, and constants. It will have the responsibility to resolve every
    types corresponding to the bits set in the mask.

    In your example, the interpreter would set the class and interface bits, as it cannot
    know which one it needs.

    Your example seems to imply that classes and interfaces should not have the same name.
    Even if it is generally the case, it is not impossible. In this case, what does your
    example take, the class or the interface ?

    Just an idea: wouldn't it be better to modify the syntax to :

    Function doSomething (Always_A_Class s) { ... }

    Function doSomething (s implements An_Interface) { ... }

    And maybe

    Function doSomething (s implements (Interface1,Interface2,...)) { ... }

    Francois
  • Marcus Boerger at Sep 12, 2007 at 1:48 pm
    Hello LAUPRETRE,

    Wednesday, September 12, 2007, 3:32:13 PM, you wrote:
    From: Pawel Stradomski

    B), but what with following language construct:

    function doSomething (Service s) {...}

    PHP tries to autoload type Service, but it can't know if it's
    looking for interface or class. Both are possible.
    Correct. I didn't consider this case because I didn't know this syntax for interfaces.
    In general it is not a question of syntax. Interfaces are purely a special
    case of classes and cannot be treated differently outside of some engine
    stuff. And even there the difference is only a flag, interface or not.

    Best regards,
    Marcus
  • Stanislav Malyshev at Sep 12, 2007 at 4:48 pm

    Yes. PHK's autoload handler is not filename-based. It works as a
    (poor man's :) runtime linker, with a symbol map. In this map,
    interfaces and classes have different symbol types. Today, when this
    handler receives a request, it cannot know if it should look for an
    interface or a class. So, it has to search both in turn.
    Looks like design flaw to me - why not index symbols by name, you can't
    have interface and class with the same name?
    very interesting to extend the feature to functions and, there,
    providing the symbol type along with the requested value becomes
    mandatory.
    If we ever extend autoloader to functions, it would be different
    autoloader anyway, since existing autoloaders can't support functions.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • LAUPRETRE François (P) at Sep 13, 2007 at 9:43 am

    From: Stanislav Malyshev

    Looks like design flaw to me - why not index symbols by name,
    you can't
    have interface and class with the same name?
    Right. I was wrong and I have suppressed the 'interface' type in the PHK autoloader.
    If we ever extend autoloader to functions, it would be different
    autoloader anyway, since existing autoloaders can't support functions.
    Are you sure we would need to create a new hook ? If the existing autoload handlers receive a request for a function, they search for a class with that name. Apart from a waste of time, it is harmless. We can even have BC : you just have to declare your autoload handler with an optional second argument, whose default value is 'class'. This would allow new autoload handlers to run on previous PHP versions.

    Francois
  • Stanislav Malyshev at Sep 13, 2007 at 5:17 pm

    Are you sure we would need to create a new hook ? If the existing
    autoload handlers receive a request for a function, they search for a
    class with that name. Apart from a waste of time, it is harmless. We
    can even have BC : you just have to declare your autoload handler
    with an optional second argument, whose default value is 'class'.
    This would allow new autoload handlers to run on previous PHP
    versions.
    Well, that might be an option too, but let's cross that bridge when we
    come to it :)
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedAug 27, '07 at 6:15a
activeSep 13, '07 at 5:17p
posts31
users11
websitephp.net

People

Translate

site design / logo © 2022 Grokbase