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
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-classesThe 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
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
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/
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
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
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_DEPRECATEDwarning.
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
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
Hi,
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
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
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:
[...]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
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
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:
[...]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
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