Hi!
That's unless the spl_autoload_register() api changes and allows to deal with
errors - require(), Exception, ...
Autoloader shouldn't produce external errors - because if it's unable to
load class, others may be able. Also, it'd be quite hard to handle such
errors - you'd have to guard
On Fri Nov 11 12:13 AM, Stas Malyshev wrote:
>
> > - MODE_DEBUG: This one can work together with the other two,
> > allowing a validation of class/interface/trait presence in the file.
> Basically,
> > it requires the file and then checks if the item exists in scope.
>
> Not sure debug adds much
Am 11.11.2011 12:53, schrieb Anthony Ferrara:
Would it not be possible that the autoloader mechanism catch all
exceptions
made by any autoloader which fails to load a class. Only if none of
the
register autoloaders can load the requested class the autoloader
mechanism
throws an AutoloadExcepti
> Yes, but even in that case the autoloader would not be triggered to
> load \Foo_Bar because if you already have used \Foo\Bar previously,
> that would have loaded \Foo_Bar as well.
Well, my original point is that what if both are not defined in the
same file. It's not that far fetched of an ide
2011/11/11 Anthony Ferrara :
[snip]
>> Actually they do not map the same file. Here is the path of each one:
>> new \Foo\Bar\Baz; => [path]/Foo/Bar/Baz.php
>> new \Foo\Bar_Baz; => [path]/Foo/Bar_Baz.php
>
> Well, as David pointed out, they do map to the same file. But even if
> they didn't, the
Hi
.. snip ..
Hm... so there should never have the normal available?
I need to think over this again then. While I tend to agree with
autoloader never triggering errors or exceptions, the debug mode is
the unique way to notice if user during developer haven't done any
mistake.
Maybe we can only
Hi!
This is actually already supported.
The SplClassLoader$mode does exactly that. The $mode can be one of these values:
- MODE_NORMAL: Throws error while attempting to include an unexistent file
Why this should even exist? It's never OK for generic autoloader to
produce any errors when it ca
Guilherme,
Comments inline
> Thanks immensely for your input.
> Without such action, it's extremely hard to improve the RFC. =)
> Awesome action from your side.
> I'll place my comments inline.
Thanks. I didn't really intend for my other comments to get so...
aggressive. I saw the proposal bei
Hi David,
On Fri, Nov 11, 2011 at 1:31 AM, David Muir wrote:
> On 11/11/2011 01:31 PM, guilhermebla...@gmail.com wrote:
>> Hi Anthony,
>>
>> Thanks immensely for your input.
>> Without such action, it's extremely hard to improve the RFC. =)
>> Awesome action from your side.
>> I'll place my comme
On 11/11/2011 01:31 PM, guilhermebla...@gmail.com wrote:
> Hi Anthony,
>
> Thanks immensely for your input.
> Without such action, it's extremely hard to improve the RFC. =)
> Awesome action from your side.
> I'll place my comments inline.
>
> On Thu, Nov 10, 2011 at 1:26 PM, Anthony Ferrara wrote
Hi Anthony,
Thanks immensely for your input.
Without such action, it's extremely hard to improve the RFC. =)
Awesome action from your side.
I'll place my comments inline.
On Thu, Nov 10, 2011 at 1:26 PM, Anthony Ferrara wrote:
> Guilherme et al,
>
> Since you asked me for feedback on how I would
11 matches
Mail list logo
