# SplClassLoader

- Thread: https://externals.io/message/56069
- Original archive: https://news-web.php.net/php.internals/56069
- Started by Will Fitch on 2011-11-04T14:22:02+00:00
- Messages: 1
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #56069 — Will Fitch — 2011-11-04T14:22:02+00:00

URL: https://externals.io/message/56069#56069

> Jonathan,
> 
> > […]
> 
> Then that's a documentation problem.  If you throw an exception in
> yours, sure that's going to cause problems for anyone else.  It's 100%
> possible (and easy) to play nice.
> 
> But that brings up another problem with PSR-0.  It's possible to use
> 100% valid PHP and have it throw a fatal error.
> 
> Let's assume a file exists named foo/bar.php
> 
> new foo\bar;
> new foo_bar;
> 
> That will fatal error 100% of the time (as long as both of those
> classes aren't in that file), since they both map to the same file,
> *and* PSR-0 mandates require instead of require_once.  So even if I
> declare an autoloader later to load my foo_bar class, it won't work
> because it'll never get there.
> 
> Additionally, since it's not checking the existance of the file, it's
> impossible for me to add a class to an existing namespace from outside
> of its root.  Say we have /lib/foo/bar/baz.php.  If I wanted to add a
> class \foo\bar\bat.php, I'd **have** to add it to that directory,
> other wise I'd get a fatal error.  It's not a far cry.  That's
> basically what Kohana does right now with their autoloader...
> 
> So that's two more inconsistencies with what's 100% valid PHP but
> could cause fatal errors with PSR-0.
Exactly.  spl_autoload_register provides the ability for autoloading to work among systems.  What it does *not* do is define the layout of files/file systems or what should happen upon a file not found.  As Jonathan noted, this is a documentation problem.  Implementing a new bit of functionality for the purpose of offering a standard is wrong IMHO.  The other problem is this would only *offer* a standard.
> 
> @Ferenec
> 
> > […]
> 
> That's something that I could get behind..
This still feels like a docs issue.  spl_autoload_register provides everything you need to create your own autoloader.  This suggestion would just add more overhead if implemented in  core (if that is your intent). 

Will

> 
> @Andre
> 
> > […]
> 
> And I don't feel that function belongs in the core at all either.
> It's there, so whatever, but at least that's consistent with how PHP
> behaves...
> 
> > […]
> 
> Well, nothing like this exists in core.  First, PSR-0 doesn't degrade
> gracefully.  If it can't map, it fatal errors.  Nothing else does so
> in the core in an area where it's 100% possible to recover anyway.
> Secondly, nothing in the core requires you to adhere to a code-level
> convention for it to work.  I'm sure there are more arguments against
> that, but eih.
> 
> Not seeing the forest for the trees?  On the opposite.  I see what
> this will open up if included.  Why can't my autoloader be put in the
> core when PSR-0 is in it?  Based on what you said, it's 100% optional,
> so why not?  Should Runkit be put in core?  Sure, it's optional to
> use, so why not?  Heck, while we're at it, all of PECL should be moved
> in core.  Who cares how stable or nice they interact with the core.
> After all, the core of the language is not like it's widely used by
> others.
> 
> The language should care about *possibility* not picking a side when
> it's trivial to implement in PHP land.  You're talking about saving 8
> or 10 lines of PHP code...  So I would argue that it's more not seeing
> the forest because you're looking too close at one tree...
> 
> Anthony
> 
> 
> 
> 
> > […]