Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55985
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
Sender: nicolas.grekas@gmail.com
In-Reply-To: <CALrkBjZtZjqtKYs22poDY4zN=ZyWVL05kcJKe1KR8KS5tw5tcg@mail.gmail.com>
References: <CADG7izUrayGSRANxakAQPvwGW08Q9QbneY8=VntCAK4qB2oE8g@mail.gmail.com>
 <CAFp73Xsibt5A_+JhxzBDvKN4_1UFofF-Yg1rHJM10HEykzBWTQ@mail.gmail.com>
 <CADG7izXo8euG2-qzhb9qkFg6Qgxzt0Ssg1jHogC9tYjxJCpyFA@mail.gmail.com> <CALrkBjZtZjqtKYs22poDY4zN=ZyWVL05kcJKe1KR8KS5tw5tcg@mail.gmail.com>
Date: Fri, 28 Oct 2011 20:13:07 +0200
Message-ID: <CAOWwgpmO24SMhK-ejx-tGVNNKrLYCuod_33Tft8sfB18h40m3Q@mail.gmail.com>
To: internals@lists.php.net
Cc: mario@include-once.org, guilhermeblanco@gmail.com, 
	"Matthew Weier O'Phinney" <weierophinney@php.net>, Mike Willbanks <pencap@gmail.com>
Content-Type: multipart/alternative; boundary=20cf3040e36289883704b05fd891
Subject: Re: [PHP-DEV] SplClassLoader and PSR-0 break language semantics
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--20cf3040e36289883704b05fd891
Content-Type: text/plain; charset=ISO-8859-1

To me, the interface found at https://wiki.php.net/rfc/splclassloader is
strange :

first, to be consistent with PSR-0, why allow changing the extension where
PSR-0 states that the only valid one is ".php"?
Why also have an interface to change the namespace separator?

Concerning userland specialization, I think the interface lacks a way to
intercept the path before "require". For example, if I want to preprocess a
file before including it, I can't with this code.

I find Symfony's interface much more powerful:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ClassLoader/UniversalClassLoader.php


About language semantics, I understand and support this reasoning:
1. case insensitivity is good because having two different classes "Foo" and
"foo" makes absolutely no sense,
2. case sensitivity is good because mixing "Foo" and "foo" usage makes
absolutely no sense.

So, having a case sensitive loader is an extremely good thing because of 2.
And having a case insensitive PHP engine is also good because of 1. To go a
little further, I even think that PHP should trigger an E_STRICT when a
class is used with mixed case (first time "Foo", later "foo") but that's for
another topic :) To me, PHP current's behavior enforces 1., which is good,
but PHP can't encourage mixing "Foo" and "foo", so no semantic is broken
when the filesystem is case sensitive.

About PSR-0 and applying the same reasoning, I don't understand why the
underscore in the namespace part is not replaced by a directory separator:
because of it's class to path transformation, PSR-0 forbids having two
different classes named A\B_C and A\B\C (they map to the same file). That is
a good think, same reasoning for 1. above. But because of the "underscore in
namespace exception", PSR-0 encourages a situation where class A_B\C can
coexists with an other class A\B\C. Why forbid A\B_C and A\B\C, then allow
A_B\C and A\B\C? That is inconsistent with argument 1. above, which we have
used to justify PSR-0 equivalence for A\B_C and A\B\C... That is
inconsistent to me.

Hope it helps :)

Nicolas

--20cf3040e36289883704b05fd891--