Re: [PHP-DEV] [RFC] Namespaces for internal classes
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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [RFC] Namespaces for internal classes
On Thu, 3 Jul 2008, Lars Strojny wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespaces for internal classes
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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [RFC] Namespaces for internal classes
On Fri, Jul 4, 2008 at 11:53 AM, Lars Strojny [EMAIL PROTECTED] wrote: 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. 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 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 -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespaces for internal classes
On Fri, 2008-07-04 at 10:28 +0200, Lars Strojny wrote:
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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespaces for internal classes
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
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [RFC] Namespaces for internal classes
Hi,
On Fri, 2008-07-04 at 11:26 +0200, Lars Strojny wrote:
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?
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Namespaces for internal classes
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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [RFC] Namespaces for internal classes
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
Re: [PHP-DEV] [RFC] Namespaces for internal classes
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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [RFC] Namespaces for internal classes
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, On Fri, Jul 4, 2008 at 3:34 PM, Lars Strojny [EMAIL PROTECTED] wrote: 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 -- 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
Re: [PHP-DEV] [RFC] Namespaces for internal classes
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 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Namespaces for internal classes
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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [RFC] Namespaces for internal classes
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
