Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56069
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
In-Reply-To: <CAAyV7nHJ4q_ao21Ryg0yWthhLFQ0sBZQH9ag9raqU9jaDGFpGg@mail.gmail.com>
Date: Fri, 4 Nov 2011 10:22:02 -0400
Cc: Jonathan Bond-Caron <jbondc@openmv.com>,
 PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <EA5E061A-E46D-4217-8C95-D1494C685134@gmail.com>
He6vcu9=BTu+qTgX=Qozde99v2xg@mail.gmail.com> <CAGMw7vHw9ksB8LVDQV5evJ8ozJ8K45MSJiR9OBnAQfCEAzCBpw@mail.gmail.com> <CAAyV7nHmQgafUqgRwT_CuQTTC+jwqgStrRXAx67baZOHOreaJA@mail.gmail.com> <00d401cc9a59$ccf273b0$66d75b10$@com> <68B9654F-EFF9-41FE-866D-B2F838C3AFCE@gmail.com> <002f01cc9ade$92c62c60$b8528520$@com> <CAAyV7nHJ4q_ao21Ryg0yWthhLFQ0sBZQH9ag9raqU9jaDGFpGg@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
X-Mailer: Apple Mail (2.1251.1)
Subject: Re: [PHP-DEV] SplClassLoader
From: will.fitch@gmail.com (Will Fitch)

On Nov 4, 2011, at 7:19 AM, Anthony Ferrara wrote:

> Jonathan,
>=20
>> The problem with spl_autoload_register() is it isn't clear what the
>> autoloading function is supposed to do if the class if not found.
>=20
> 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.
>=20
> But that brings up another problem with PSR-0.  It's possible to use
> 100% valid PHP and have it throw a fatal error.
>=20
> Let's assume a file exists named foo/bar.php
>=20
> new foo\bar;
> new foo_bar;
>=20
> 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.
>=20
> 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...
>=20
> 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.
>=20
> @Ferenec
>=20
>> I think that the best solution would be having a generic autoloader =
infrastructure in the core, and having separate autoloading =
strategies(http://en.wikipedia.org/wiki/Strategy_pattern) offered, and =
one of them could be PSR-0(we could also add the PEAR/PEAR2 autoloader, =
etc.).
>=20
> 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).=20

Will

>=20
> @Andre
>=20
>> It will be a more modern alternative to =
http://www.php.net/manual/en/function.spl-autoload.php
>=20
> 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...
>=20
>> So yes, there is already something like this in core, so I really =
don't get why you are so against this, not seeing the wood for the =
trees? :)
>=20
> 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.
>=20
> 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.
>=20
> 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...
>=20
> Anthony
>=20
>=20
>=20
> On Fri, Nov 4, 2011 at 6:43 AM, Jonathan Bond-Caron =
<jbondc@openmv.com> wrote:
>> On Thu Nov 3 03:06 PM, Will Fitch wrote:
>>> Wouldn't you consider spl_autoload_register an interoperability
>>> solution?  Only your defined autoloading function would then need to
>>> know how your file system is structured, there'd be no need for
>>> include_path declarations and you wouldn't have to explicitly =
declare
>>> paths for each class.
>>>=20
>>=20
>> The problem with spl_autoload_register() is it isn't clear what the
>> autoloading function is supposed to do if the class if not found.
>> So no I don't think spl_autoload_register() solves an =
interoperability
>> problem. SplClassLoader somewhat does a better job by forcing a =
common
>> implementation...
>>=20
>> function FrameworkA_autoload($class) {
>>  if( !isset($AmapToFile[$class]) )
>>     throw new Exception('Class '. $class . ' not found!');
>>=20
>>  include_once($AmapToFile[$class]);
>> }
>> function FrameworkB_autoload($class) {
>>  require_once($BmapToFile[$class]);
>> }
>> function FrameworkC_autoload($class) {
>>  include_once($CmapToFile[$class]);
>> }
>>=20
>> spl_autoload_register('FrameworkA_autoload');
>> spl_autoload_register('FrameworkB_autoload');
>> spl_autoload_register('FrameworkC_autoload');
>>=20
>> So both 'FrameworkB_autoload', 'FrameworkC_autoload' are never =
called.
>>=20
>> Btw, I would hope that any 'standard' would actually that try to talk =
about
>> other autoloaders and how they should behave.
>>=20
>> https://gist.github.com/221634
>>=20
>> See comments about include() or require()
>>=20
>>=20
>>=20