Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38742
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 208.113.200.5 as permitted sender)
In-Reply-To: <1215076043.7021.10.camel@localhost>
References: <1215076043.7021.10.camel@localhost>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <4C2C6BC2-4DD3-443A-A411-C6B0AFA80058@php.net>
Cc: php-dev List <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Date: Thu, 3 Jul 2008 16:31:48 -0500
To: Lars Strojny <lars@strojny.net>
Subject: Re: [PHP-DEV] [RFC] Namespaces for internal classes
From: tswicegood@php.net (Travis Swicegood)

Hey Lars;

On Jul 3, 2008, at 4:07 AM, Lars Strojny wrote:

> one thing on my mind is the current naming of our internal classes. I
> could say the same for our functions but no, I don't have plans to  
> save
> the universe, saving the world should be enough for now. So I've tried
> to dig through the ext/spl-package as an example how to implement
> namespaces for internal classes. Also I did it for SPL now, I would go
> on further and discuss such changes e.g. for ext/intl.
> And here is the resulting
> RFC: http://wiki.php.net/rfc/namespaces-for-internal-classes
>
> The RFC is not ready yet but I want to get feedback on it. The  
> integral
> part is the list of renamings and that's fixed, so you can expect a  
> bit
> more prose :)
> Having that for 5.3 seems like a good idea, as we have a) a number of
> added SPL classes, b) most likely new extensions introducing new  
> classes
> (ext/intl, ext/phar), c) having it is 5.3 would allow us seemless
> transistions to newer PHP versions.

+1 on the idea, but I'm not huge on the current naming structure.   
Here's just a few things that I would change:

* Completely bike shedding, but does "Recursive" need its own level?   
RecursiveArray reads better than having Array at two different levels  
to me.

* Again, bike shedding, but I like the name ArrayIterator - it  
defines exactly what the class is while Array doesn't convey very  
well by itself.  You have to look at the full name in order to  
understand the process.  This also becomes ambiguous when you're  
reading the code in PHP.  What does "$a = new Array($some_array);"  
do?  You have to go back to the "uses" declaration at the top to  
figure it out.  This is true for most of the names I'm seeing here.   
Range, Info, Object, Logic, etc.  What kind of Range, Info about  
what, a plain Object, an ArrayObject, or something else?

You end up with more verbose names by going to a PEAR1 style of  
naming convention because you have to use the entire name with the  
namespace in order to convey what the code is supposed to be doing.   
I would stick with names more closely related to the original names  
and add "spl::" (see next comment for lowerspace) to signify that  
they're part of SPL.  So instead of RecursiveArrayIterator, you have  
spl::RecursiveArrayIterator; SplFileInfo becomes spl::FileInfo, etc.

* I would change everything except the final class name in the full  
name to be lowercase.  Using your existing examples:   
Spl::List::DoublyLinked would be spl::list::DoublyLinked, or better  
yet spl::DoublyLinkedList, etc.  This helps denote what is a class  
and what is part of the namespace name.  In the original examples,  
its ambiguous as to what can be instantiated.  Are Spl and Spl::List  
classes that can be instantiated?  Moving to the lower space  
convention makes it easy to denote what is a class and what is just  
part of the namespace.  This follows the path created by several  
other languages.

Thanks for bringing this up.  Hopefully we can start using namespaces  
in at least some parts of PHP to help promote their best uses  
throughout the language.

-T