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 f
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 does
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 fo
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
Hi,
> From: Dmitry Stogov [mailto:[EMAIL PROTECTED]
>
> 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
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 Malysh
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:
In this case PHP first looks for
Existing __autoload() will work fine with code without namespaces.
Dmitry.
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 28, 2007 11:44 AM
> To: Dmitry Stogov
> Cc: 'PHP Internals List'
> Subject: Re: [PHP-DE
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 ar
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
Stanislav Malyshev wrote:
>> > 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 pa
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
> matchin
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
reaso
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 th
would be consistent simple and clear.
also I don't see what would be gained from being allowed
to do:
Thanks. Dmitry.
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: Monday, August 27, 2007 9:49 PM
To: Dmitry Stogov
Cc: 'PHP Internals List'
Su
y, August 27, 2007 9:49 PM
> To: Dmitry Stogov
> Cc: 'PHP Internals List'
> Subject: Re: [PHP-DEV] Namespaces and __autoload()
>
>
> > > namespace Foo;
> > throw new Exception;
> >
> > In this case PHP first looks for Foo::Exception and only th
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 autol
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.
Index: Zend/zend_builtin_functions.c
===
18 matches
Mail list logo
