Everything

php

Namespaces and __autoload()

php.internals

Dmitry Stogov

19 years ago

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.

Stanislav Malyshev

19 years ago

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

19 years ago

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.

Jochem Maas

19 years ago

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

Stanislav Malyshev

19 years ago

> 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

19 years ago

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

Greg Beaver

19 years ago

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

Greg Beaver

19 years ago

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

19 years ago

> 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

19 years ago

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:

Stanislav Malyshev

19 years ago

> 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

19 years ago

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

Dmitry Stogov

19 years ago

Existing __autoload() will work fine with code without namespaces.

Dmitry.

LAUPRETRE François (P)

18 years ago

Hi,

> From: Dmitry Stogov [mailto:dmitry@zend.com]
>
> 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

18 years ago

> 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 Börger

18 years ago

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

18 years ago

> 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 Börger

18 years ago

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)

18 years ago

> From: Stanislav Malyshev [mailto:stas@zend.com]
>
> 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

18 years ago

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

18 years ago

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

--
http://stut.net/

LAUPRETRE François (P)

18 years ago

> From: Stut [mailto:stuttle@gmail.com]
>
> 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

18 years ago

LAUPRETRE François (P) wrote:

>> From: Stut [mailto:stuttle@gmail.com]
>>
>> 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

--
http://stut.net/

Paweł Stradomski

18 years ago

W liście Stut z dnia środa, 12 września 2007 15:59:

> LAUPRETRE François (P) wrote:
> >> From: Stut [mailto:stuttle@gmail.com]
> >>
> >> 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

18 years ago

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

18 years ago

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)

18 years ago

> From: Pawel Stradomski [mailto:pstradomski@gmail.com]
>
> 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 Börger

18 years ago

Hello LAUPRETRE,

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

>> From: Pawel Stradomski [mailto:pstradomski@gmail.com]
>>
>> 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

18 years ago

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

18 years ago

> From: Stanislav Malyshev [mailto:stas@zend.com]
>
> 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

18 years ago

> 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