Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Native Namespace Code Prep #1721
This PR adds in the root namespace backslash on calls to internal PHP and SPL classes. This will facilitate the platform moving to native PHP namespaces, whenever that may be.
More info can be found here: http://www.php.net/manual/en/language.namespaces.faq.php#language.namespaces.faq.globalclass
Also, I've replaced some explicit calls to class names with
This PR does not break B/C at all, as the whole codebase is already operating in the root/global namespace. But this will need to be done when we do move to namespaces, so I thought I could help that along.
No unit tests were harmed in the making of this pull request.
Thanks Don. Would you mind adding a page to the docs, probably namspacing.md under the Code Standards heading, which outlines what we need to be aware of when writing, and obviously reviewing, code?
It makes sense for the platform, but I think this could potentially give the CMS some grief with extension developers that want to retain support for PHP 5.2 on CMS 2.5 yet maintain a dual 2.5+3 version package. I don't have a problem with the change but it's probably worth giving the CMS dev list a heads up that we are talking about this.
This comment has been minimized.
This comment has been minimized.Show comment Hide comment
I was looking at adding to the documentation here - https://github.com/joomla/joomla-platform/blob/staging/docs/manual/en-US/coding-standards/chapters/php.md#class-definitions - but it's probably best to make it it's own page, since I'm sure the section will continue to grow. I'll get that added as well as inform the CMS dev list.
It's not completed yet, but it's what I could think of for now.
As for that compatibility layer section. We can take it or leave it, it's just my thoughts of what I would like to see happen, even if I maintain that layer myself for the 2 revisions after going fully namespaced.
I agree - a lot of the compatibility needs could be buffered in the legacy tree, and then the remainder picked up by the proposed compatibility layer.
As you suggested in the mailing list, I think it's a great idea to hold off until 13.1 to merge this. Want to change the milestone?