# [RFC] Namespaces for internal classes - Thread: https://externals.io/message/38730 - Original archive: https://news-web.php.net/php.internals/38730 - Started by Lars Strojny on 2008-07-03T09:07:23+00:00 - Messages: 14 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #38730 — Lars Strojny — 2008-07-03T09:07:23+00:00 URL: https://externals.io/message/38730#38730 Hello everbody, 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. cu, Lars --- ## #38742 — Travis Swicegood — 2008-07-03T21:31:48+00:00 URL: https://externals.io/message/38730#38742 · In reply to: #38730 Hey Lars; > 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 --- ## #38746 — Lars Strojny — 2008-07-04T07:53:36+00:00 URL: https://externals.io/message/38730#38746 · In reply to: #38742 Hi Travis, Am Donnerstag, den 03.07.2008, 16:31 -0500 schrieb Travis Swicegood: > > * Completely bike shedding, but does "Recursive" need its own level? > RecursiveArray reads better than having Array at two different levels > to me. Alright, I will change that. > * 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? That's what "use" is for. You would do "use Spl::Iterator::Array as ArrayIterator" and than "new Array" becomes "new ArrayIterator" which is pretty clear. Of course, we should add that to the docs if we go that way. > 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 see it more as packages. "Spl" is a package consisting of several subpackages like "Iterator", "Lists", etc. pp. > * 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. I don't really have an argument against that, except that I honestly don't like it, sorry :). I'm not sure how I could assume that "Spl::List" can be instantiated, as I miss the hint that it exists. If Spl::List is a problem, everybody out there must have a hard time trying to figure out that there is no StringIterator because ArrayIterator exists? cu, Lars --- ## #38748 — Derick Rethans — 2008-07-04T08:14:41+00:00 URL: https://externals.io/message/38730#38748 · In reply to: #38730 > RFC: http://wiki.php.net/rfc/namespaces-for-internal-classes I'd say this is a BIG no-no. PHP owns the top-level namespace. Why make things harder? And on top of that, you're suggesting just to break code for no good reason in "Backwards compatibility and other constraints". regards, Derick --- ## #38749 — Lars Strojny — 2008-07-04T08:28:55+00:00 URL: https://externals.io/message/38730#38749 · In reply to: #38748 Hi Derick, Am Freitag, den 04.07.2008, 10:14 +0200 schrieb Derick Rethans: > I'd say this is a BIG no-no. PHP owns the top-level namespace. Why > make things harder? And on top of that, you're suggesting just to > break code for no good reason in "Backwards compatibility and other > constraints". Quoting the proposal: "The current names are available as deprecated aliases until their removal". This means that until we decide to remove the old names, the current ones are available. I'm currently investigating how to implement an ADD_DEPRECATED_CLASS_ALIAS-macro. Classes/interfaces created with this warning would trigger an `E_DEPRECATED` warning. cu, Lars --- ## #38751 — Alexey Zakhlestin — 2008-07-04T08:33:43+00:00 URL: https://externals.io/message/38730#38751 · In reply to: #38746 > Am Donnerstag, den 03.07.2008, 16:31 -0500 schrieb Travis Swicegood: > > […] > > Alright, I will change that. > > > […] > > That's what "use" is for. You would do "use Spl::Iterator::Array as > ArrayIterator" and than "new Array" becomes "new ArrayIterator" which is > pretty clear. Of course, we should add that to the docs if we go that > way. > > > […] > > I see it more as packages. "Spl" is a package consisting of several > subpackages like "Iterator", "Lists", etc. pp. in this case, I think the following would be better as a naming scheme: Spl::Iterators::ArrayIterator Spl::Iterators::RecursiveArrayIterator Spl::Lists::DoublyLinkedList Spl::Lists::Queue this way, class always has "meaningful name" and subpackage is marked with trailing "s". This would be easy to read from right to left "Queue which is one of the Lists, which is one of the packages of SPL" > > > […] > > I don't really have an argument against that, except that I honestly > don't like it, sorry :). I'm not sure how I could assume that > "Spl::List" can be instantiated, as I miss the hint that it exists. If > Spl::List is a problem, everybody out there must have a hard time trying > to figure out that there is no StringIterator because ArrayIterator > exists? > > cu, Lars > -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #38755 — johannes@php.net — 2008-07-04T09:15:28+00:00 URL: https://externals.io/message/38730#38755 · In reply to: #38749 > Hi Derick, > > Am Freitag, den 04.07.2008, 10:14 +0200 schrieb Derick Rethans: > > […] > > Quoting the proposal: "The current names are available as deprecated > aliases until their removal". This means that until we decide to remove > the old names, the current ones are available. I'm currently > investigating how to implement an ADD_DEPRECATED_CLASS_ALIAS-macro. > Classes/interfaces created with this warning would trigger an > `E_DEPRECATED` warning. That's not entirely true, there are minor BC breaks: Let's say Bar is an alias for Foo::Bar. now to $r = new ReflectionClass('Bar'); echo $r->getName(); and you'll get 'Foo::Bar' as that's the name in the CE, same goes for error messages, stack traces, ... (I'Ve seen people parsing them...) johannes --- ## #38757 — Lars Strojny — 2008-07-04T09:26:36+00:00 URL: https://externals.io/message/38730#38757 · In reply to: #38755 Hi Johannes, Am Freitag, den 04.07.2008, 11:15 +0200 schrieb Johannes Schlüter: [...] > That's not entirely true, there are minor BC breaks: Let's say Bar is an > alias for Foo::Bar. now to $r = new ReflectionClass('Bar'); echo > $r->getName(); and you'll get 'Foo::Bar' as that's the name in the CE, > same goes for error messages, stack traces, ... (I'Ve seen people > parsing them...) Didn't thought of that, thanks for the heads up. In your opinion, would that be a show stopper? cu, Lars --- ## #38765 — johannes@php.net — 2008-07-04T11:56:43+00:00 URL: https://externals.io/message/38730#38765 · In reply to: #38757 Hi, > Am Freitag, den 04.07.2008, 11:15 +0200 schrieb Johannes Schlüter: > [...] > > […] > > Didn't thought of that, thanks for the heads up. In your opinion, would > that be a show stopper? 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. johannes --- ## #38766 — Lars Strojny — 2008-07-04T12:31:44+00:00 URL: https://externals.io/message/38730#38766 · In reply to: #38765 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 --- ## #38767 — Etienne Kneuss — 2008-07-04T12:50:20+00:00 URL: https://externals.io/message/38730#38767 · In reply to: #38766 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 > Hi Johannes, > > Am Freitag, den 04.07.2008, 13:56 +0200 schrieb Johannes Schlüter: > [...] > > […] > > 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 --- ## #38768 — Lars Strojny — 2008-07-04T13:34:40+00:00 URL: https://externals.io/message/38730#38768 · In reply to: #38767 Hi Etienne, Am Freitag, den 04.07.2008, 14:50 +0200 schrieb Etienne Kneuss: [...] > a big -1 from me on the namings > I really see no point in having: > > use Spl::Exception; > throw new Logic; use Spl::Exception::Logic as LogicException; throw new LogicException(); Besides that, what we should keep in mind, whatever structure we define it is likely that this structure sends an important signal towards other projects (frameworks, libraries) and how they use namespaces. My objection with your proposed method is, that while it fixes the problem of clashes, it fails to structure the classes in the package "Spl". cu, Lars --- ## #38769 — Etienne Kneuss — 2008-07-04T14:03:10+00:00 URL: https://externals.io/message/38730#38769 · In reply to: #38768 Hi, but there is already a structure in the namings of classes, and it's already documented: " Iterators and Exceptions are however simply postfixed with "Iterator" and "Exception." Examples: " IMO this rule should still be valid in namespaces so I'd group iterators along with what they iterates on, rather than grouping them together. This will be especially useful when classes like Graph will appear, as they will have multiple different iterators/visitors. If we have to rename what we import in order to make the code clear (i.e your example about LogicException), it looks like a sign that the namespace should be named/grouped differently. Besides, I don't believe "List" is a correct term to group queue/stack/heap/.... Spl::Datastructure sounds more correct. Regards, > Hi Etienne, > > Am Freitag, den 04.07.2008, 14:50 +0200 schrieb Etienne Kneuss: > [...] > > […] > > use Spl::Exception::Logic as LogicException; > throw new LogicException(); > > Besides that, what we should keep in mind, whatever structure we define > it is likely that this structure sends an important signal towards other > projects (frameworks, libraries) and how they use namespaces. My > objection with your proposed method is, that while it fixes the problem > of clashes, it fails to structure the classes in the package "Spl". > > 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 --- ## #38772 — Larry Garfield — 2008-07-04T18:15:04+00:00 URL: https://externals.io/message/38730#38772 · In reply to: #38766 On Friday 04 July 2008 7:31:44 am Lars Strojny wrote: > Hi Johannes, > 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 If I may... From a userland perspective, the potential pitfall I see with namespacing PHP core stuff is that namespaces allow you to completely rename something. If you have to "use" something in order to use it, the odds are quite good of different people using different aliased names, even if they don't need to. I have worked with people who I am certain would do the following just to be difficult (or because they don't actually realize what a bad idea the following is): use Spl::Lists::Queue as MyFancyArray; $f = new MyFancyArray(); ... Naturally you can't prevent that for namespaced code without removing aliases, which is not an option, so some of that is going to happen anyway. But it would really really suck if I have to keep track of what PHP core/SPL classes or functions are in use in a given script not just by name but also by what this particular developer decided to alias them to because he was feeling lazy on a particular Friday last year. Doing that for userspace code will be challenging enough. :-) -- Larry Garfield larry@garfieldtech.com