a big -1 from me on the namings
I really see no point in having:

use Spl::Exception;
throw new Logic;

It makes the code hard to understand with no reason.
IMO a single SPL namespace is enough, and it solves the naming
problems we have with SPL.


On Fri, Jul 4, 2008 at 2:31 PM, Lars Strojny <[EMAIL PROTECTED]> wrote:
> Hi Johannes,
> Am Freitag, den 04.07.2008, 13:56 +0200 schrieb Johannes Schlüter:
> [...]
>> Depends ;-)
>> Main point: There's no such thing as "no BC break". So we have to decide
>> whether that BC break (hoping it's the only one) is less a problem than
>> having an inconsistent naming scheme. (... wait - isn't PHP famous for
>> being inconsistent?) The question there is: Where do we want to go
>> tomorrow? Do we want to namespace internal stuff? All of it? Or do we
>> still want to own the global namespace and put internal classes there?
>> As long as that isn't decided it's hard to make a decision about
>> aliasing.
>> So I'd say we need the RFC which defines rules for future stuff
>> (All/"non-core" parts/nothing in namespaces) and then the consequences
>> for existing stuff.
> Alright, that's what my RFC was aiming for. Maybe from the wrong
> direction. I wanted to do it exemplary for SPL and go on further for all
> the other extensions we bundle in core. Namespacing everything is the
> only way to reliably avoid collisions as the other option would be to
> prefix anything except core. But what if we move an extension out of
> core, should it be prefixed than?
> cu, Lars

Etienne Kneuss

Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to