Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56031
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: multipart/alternative; boundary="Apple-Mail=_7EACBCA6-BE7E-478B-97E3-4BDCA2BAF7CA"
In-Reply-To: <CAAyV7nHmQgafUqgRwT_CuQTTC+jwqgStrRXAx67baZOHOreaJA@mail.gmail.com>
Date: Thu, 3 Nov 2011 11:27:29 -0400
Cc: =?iso-8859-1?Q?Andr=E9_R=F8mcke?= <ar@ez.no>,
 Laruence <laruence@php.net>,
 "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>,
 David Coallier <davidc@php.net>,
 Pierre Joye <pierre.php@gmail.com>,
 Mike Willbanks <pencap@gmail.com>,
 PHP Internals List <internals@lists.php.net>
Message-ID: <927F7C8A-DF8E-467D-8281-5DDDCAB7EC86@gmail.com>
mq07p8L9J5KHeg-3OyvuWyDUa5tw@mail.gmail.com> <CAGMw7vGhLYfHU_0MbwLvQ4aCfGWDVgFHp2c1LfE_qcjxC8yc-w@mail.gmail.com> <CABBJUpcSWT4Dt8hRhLRVMHHe6vcu9=BTu+qTgX=Qozde99v2xg@mail.gmail.com> <CAGMw7vHw9ksB8LVDQV5evJ8ozJ8K45MSJiR9OBnAQfCEAzCBpw@mail.gmail.com> <CAAyV7nHmQgafUqgRwT_CuQTTC+jwqgStrRXAx67baZOHOreaJA@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)

--Apple-Mail=_7EACBCA6-BE7E-478B-97E3-4BDCA2BAF7CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I couldn't agree more with Anthony.  In conjunction with that, I would =
continue to question the full benefit to the community.  How many =
existing code bases/frameworks out there would implement this in favor =
of their existing solution? =20

Will

On Nov 3, 2011, at 11:19 AM, Anthony Ferrara wrote:

> Can I make a point here.
>=20
> Why the heck are we caring about the performance of the autoloader at
> all here?  The filesystem operations necessary (at least the stat()
> call) will greatly dominate any string function.  And considering that
> even the biggest framework only has perhaps a few hundred classes,
> you're talking about incredibly small performance gains here.  Even if
> you save a microsecond in string operations (try it, even in PHP the
> string operations can be done in around 10 or 20 microseconds), after
> all classes are loaded you're only talking about a 1 or 2 milliseconds
> of gain in the application.
>=20
> I'm not saying that we shouldn't try to save time where we can, but
> given the controversial nature of this addition, I don't think that a
> micro-optimization (which is what this really is) should be used as a
> justification for why it should be included.  It's not like we're
> talking about implementing a computationally difficult task into C
> (such as a cryptographic algorithm) where putting it into C would
> create a huge performance gain.  We're talking about implementing a
> function which already is dominated by non-computational overhead into
> C to save a few milliseconds.  The number of instances that will
> benefit from such an addition are incredibly small.  Saving 2
> milliseconds on an application (that likely takes hundreds of
> milliseconds to render) would require a huge number of requests to
> amortize into an actual measurable benefit.  And those that do benefit
> would have access to their server farm to add the pecl extension
> anyway.  So there's really no practical performance gain to the
> community as a whole, hence confirming that this is a
> micro-optimization.
>=20
> Personally I feel that this does not belong in the core (especially
> not yet as with the inconsistencies).
>=20
> But that's besides the point.  I just want to emphasize the point that
> performance should not be a criteria for justifying it going into the
> core...
>=20
> Anthony
>=20
>=20
> On Thu, Nov 3, 2011 at 10:56 AM, Andr=E9 R=F8mcke <ar@ez.no> wrote:
>> On Thu, Oct 27, 2011 at 4:30 AM, Laruence <laruence@php.net> wrote:
>>=20
>>> 2011/10/26 Andr=E9 R=F8mcke <ar@ez.no>:
>>>> On Tue, Oct 25, 2011 at 4:39 AM, guilhermeblanco@gmail.com <
>>>> guilhermeblanco@gmail.com> wrote:
>>>>=20
>>>>> Hi internals,
>>>>>=20
>>>>> For all those interested, I have updated the RFC with better
>>>>> explanation, included example implementation and also example =
usage.
>>>>> If you have any other wishes, doubts, etc, feel free to ask on =
this
>>>>> thread and I'll quickly answer here and also update the RFC
>>>>> accordingly.
>>>>>=20
>>>>=20
>>>>=20
>>>> As sent to the PHP-SWG list, a small change / addition to PSR-0 =
would
>>>> simplify the matching considerably.
>>>>=20
>>>> If this rule:
>>>> * Each =93_=94 character in the CLASS NAME is converted to a
>>>> DIRECTORY_SEPARATOR. The =93_=94 character has no special meaning =
in the
>>>> namespace.
>>>>=20
>>>> is changed to
>>>> * Each =93_=94 character in the CLASS NAME and NAMESPACE is =
converted to a
>>>> DIRECTORY_SEPARATOR.
>>> There is a internal autoloader in
>>> =
Yaf(http://svn.php.net/viewvc/pecl/yaf/trunk/yaf_loader.c?view=3Dmarkup),
>>> in it the T_NS_SEPARATOR will convert to be "_", then convert to be
>>> DIRECTORY_SEPARATOR.
>>>=20
>>> thanks
>>>=20
>>=20
>>=20
>> As mentioned by others this will have to go into a new PSR standard =
as
>> PSR-0 was accepted 2 years ago.
>>=20
>> And assuming that a C implementation will greatly out-weight the =
reduced
>> amount of str functions in terms performance we should not block this
>> process to get it into 5.4 by taking up off-topic subjects like =
mentioning
>> things not part of PSR-0.
>>=20
>> But!
>>=20
>> The implementation proposal (rfc) should be adjusted to be
>> forward compatible, including support for several namespaces pr =
instance
>> (mention by several on PSR mailing list) imho.
>>=20
>> Possible example (additional arguments can be added later when more
>> features are added, aka a PSR-1 mode):
>>=20
>> new SplClassLoader( array( 'Doctrine\Common' =3D> '/path/to/doctrine' =
) );
>>=20
>>=20
>> Or something like this (if we want the options to be an array):
>>=20
>> new SplClassLoader( array( 'ns' =3D> array( 'Doctrine\Common' =3D>
>> '/path/to/doctrine' ) ) );
>>=20
>>=20
>> For documentation and argument validation, imo the former approach =
would be
>> better.
>> So what is the status here? thread has been silent for a while.
>>=20
>>=20
>>>>=20
>>>> Or a strict mode is added to enable that, then you'll reduce 6 =
string
>>>> function to 2, and still have backward support for PEAR class =
naming(w/o
>>>> namespace).
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>> The url for the RFC is: https://wiki.php.net/rfc/splclassloader
>>>>>=20
>>>>> Cheers,
>>>>>=20
>>>>> On Mon, Oct 24, 2011 at 7:55 PM, David Coallier <davidc@php.net> =
wrote:
>>>>>>>=20
>>>>>>> Could you open a FR at bugs.php.net and attach the patch to it
>>> please?
>>>>>>> Could be easier to track  (and the # to the RFC too :)
>>>>>>>=20
>>>>>>=20
>>>>>> Yeah I'll do that once I have the tests adjusted and once I know =
the
>>>>>> patch actually works as expected.
>>>>>>=20
>>>>>> --
>>>>>> David Coallier
>>>>>>=20
>>>>>> --
>>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> --
>>>>> Guilherme Blanco
>>>>> Mobile: +55 (11) 8118-4422
>>>>> MSN: guilhermeblanco@hotmail.com
>>>>> S=E3o Paulo - SP/Brazil
>>>>>=20
>>>>> --
>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>>=20
>>>=20
>>> --
>>> Laruence  Xinchen Hui
>>> http://www.laruence.com/
>>>=20
>>=20
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20


--Apple-Mail=_7EACBCA6-BE7E-478B-97E3-4BDCA2BAF7CA--