On 2011-10-28, Nicolas Grekas wrote:
> 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
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 specializ
Hello,
> Already answered before. Performance is important. A native C
> > implementation is much faster than a PHP code implementation.
>
> Well, that's always a safe assumption. But a shiny benchmark would be
> useful in this review.
> Interesting hard fact would to be know if -for the overall f
Hello Guilherme,
2011/10/27 guilhermebla...@gmail.com :
>
> PHP-Standard list is also opened.
... since a few days.
But I'll happily take the discussion there. As I feel it doesn't belong here.
Discussing PSR-0 or how it came to be is entirely off-topic (and would be
rude).
We are just discussin
On 2011-10-26, Pierre Joye wrote:
> On Thu, Oct 27, 2011 at 1:07 AM, wrote:
> > 2011/10/26 Matthew Weier O'Phinney :
> > > My main point, however, is that the standard was ratified quite some
> > > time ago already -- we just now have parties interested in creating a
> > > C-level implementation
Hi Mario,
On Wed, Oct 26, 2011 at 9:07 PM, wrote:
> 2011/10/26 Matthew Weier O'Phinney :
>>
>> My main point, however, is that the standard was ratified quite some
>> time ago already -- we just now have parties interested in creating a
>> C-level implementation compatible with the standard to (
On Thu, Oct 27, 2011 at 1:07 AM, wrote:
> 2011/10/26 Matthew Weier O'Phinney :
>>
>> My main point, however, is that the standard was ratified quite some
>> time ago already -- we just now have parties interested in creating a
>> C-level implementation compatible with the standard to (a) make usa
2011/10/26 Matthew Weier O'Phinney :
>
> My main point, however, is that the standard was ratified quite some
> time ago already -- we just now have parties interested in creating a
> C-level implementation compatible with the standard to (a) make usage
> simpler, and (b) better optimize performanc
