Hi, 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. Regards 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 http://www.colder.ch 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
