Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56131
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFp73XtYWwQOVnHKdNtNhkNNg2EhoQN1S8ZDnJnQpMC1E31xXA@mail.gmail.com>
References: <CALa-LwbbENc-ZQ=+5SJdA0P3Oa5mH6sJmvhYTm30J2p+9Sg5zg@mail.gmail.com>
	<4EB81703.7030605@hoa-project.net>
	<CAFp73XtYWwQOVnHKdNtNhkNNg2EhoQN1S8ZDnJnQpMC1E31xXA@mail.gmail.com>
Date: Mon, 7 Nov 2011 15:37:40 -0500
Message-ID: <CAAyV7nHDfn2L8sND2NK7phpDZYbRb9_RVY+oPL732H7uJW_LQw@mail.gmail.com>
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>
Cc: ivan.enderlin@hoa-project.net, David Coallier <davidc@php.net>, 
	internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] SplClassLoader RFC Voting phase
From: ircmaxell@gmail.com (Anthony Ferrara)

> I updated the RFC a few hours ago based on a lengthy discussion in> php-s=
tandards.

Point of order.  Discussions on RFCs are supposed to happen on the
internals list.  That's the point of an open RFC process, so that the
discussion and justification can be made public for all to see.  The
RFCs under discussion should not be changed during this time with the
exception of changes requested in the formal discussion.

If the RFC was changing during the discussion phase due to closed-door
discussions, then I think that it voids the discussion phase entirely.

Why am I so adamant against this RFC?  Simple: the implementation
won't do what people have been promised.  There are dozens of
*different* PSR-0 implementations out there (Heck, Symfony has **5**
of them).  Why are we trying to lock the core down to the most
limiting version?  And at that point, why isn't the
http://pecl.php.net/package/automap Automap extension being considered
for inclusion instead/in addition?  Rather than trying to find the
*right* solution for the core, the focus has been on *a* solution.
That's the wrong approach in my opinion and I fear that projects and
users will suffer in the long run.  And that doesn't even hint at the
deficiencies that others and myself have pointed out with PSR-0
itself.

I don't want to beat a dead horse here, but I still think that it's
important to solidify the RFC prior to the voting phase can
legitimately happen.  Otherwise people are voting on a moving target
(which isn't reasonable IMHO).  I won't bring it up again, but I feel
it's important to assert this officially...

Anthony

On Mon, Nov 7, 2011 at 12:41 PM, guilhermeblanco@gmail.com
<guilhermeblanco@gmail.com> wrote:
> Hi Ivan,
>
> I updated the RFC a few hours ago based on a lengthy discussion in
> php-standards.
> It seems after these 2 years of PSR-0, all the rules are kept, but
> some changes were made to the original code (the one in RFC) to
> enhance the support. They are:
>
> - Multiple paths per namespace
> - Silent mode
>
> The first one seems very useful in a component based library, while
> the second is intended to not explode the class required if you have
> multiple instances of ClassLoader.
> I added quickly the methods ->registerNamespace() and
> ->registerPrefix() to RFC, but I still require to update the
> SplClassLoader PHP based version.
>
> By now, you can either look at Symfony 2, Doctrine 2 or Zend Framework
> 2 to see the implementation details.
>
> Cheers,
>
> On Mon, Nov 7, 2011 at 3:36 PM, Ivan Enderlin @ Hoa
> <ivan.enderlin@hoa-project.net> wrote:
>> On 07/11/11 14:41, David Coallier wrote:
>>>
>>> Hey everyone,
>>
>> Hi David,
>>
>>> After lengthy discussions and various opinion, we believe this issue
>>> has been discussed at length and the PSR-0 has had this standard
>>> effective for the past 1.5 year.
>>>
>>> The SplClassLoader RFC has moved to "voting" stage. Please cast your
>>> votes at https://wiki.php.net/rfc/splclassloader/vote
>>>
>>> Thank you very much for all the interest showed so far,
>>
>> I'm very interesting by SplClassLoader but the RFC is not consistent. Yo=
u
>> give an example that actually does not follow the proposed implementatio=
n
>> (e.g. the registerNamespace() and registerPrefix() methods are not prese=
nt
>> in the proposed implementation).
>>
>> I have a solution in Hoa (a set of libraries, please, see my signature) =
for
>> supporting multiple paths per namespace. How can I contribute knowing th=
at
>> Hoa's implement follows the RFC (since it's beginning).
>>
>> Best regards.
>>
>> --
>> Ivan Enderlin
>> Developer of Hoa
>> http://hoa.42/ or http://hoa-project.net/
>>
>> PhD. student at LIFC/DISC (Vesontio) and INRIA (Cassis)
>> http://lifc.univ-fcomte.fr/ and http://www.inria.fr/
>>
>> Member of HTML and WebApps Working Group of W3C
>> http://w3.org/
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
>
> --
> Guilherme Blanco
> Mobile: +55 (11) 8118-4422
> MSN: guilhermeblanco@hotmail.com
> S=E3o Paulo - SP/Brazil
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>