rfc:backslashnamespaces

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
rfc:backslashnamespaces [2008/10/25 06:32]
cellog created
rfc:backslashnamespaces [2008/10/25 13:57]
cellog oops, all / should be \
Line 1: Line 1:
 ====== Request for Comments: problems of namespaces and potential solutions ====== ====== Request for Comments: problems of namespaces and potential solutions ======
-  * Version: 1.0+  * Version: 1.1
   * Date: 2008-10-25   * Date: 2008-10-25
   * Author: Gregory Beaver <​cellog@php.net>​   * Author: Gregory Beaver <​cellog@php.net>​
Line 34: Line 34:
   * no naming conflicts possible between functions/​static methods, class constants/​namespace constants   * no naming conflicts possible between functions/​static methods, class constants/​namespace constants
   * no syntax changes for those using namespaces for classes   * no syntax changes for those using namespaces for classes
 +  * probably the smallest codebase change
  
 ==== Problems ==== ==== Problems ====
Line 125: Line 126:
  
   * move all static method calls to -> syntax   * move all static method calls to -> syntax
-  * introduce E_DEPRECATED for :: calls that resolve to static method, remove ​in PHP 6+  * introduce ​E_STRICT (or E_DEPRECATEDfor :: calls that resolve to static method in PHP 6, but allow both syntaxes without error in PHP 5.3
  
 The second way is going to be a terrible headache for all OO authors, past and present, and will prevent migration to PHP 5.3 for those who are only looking for security fixes and performance improvements. ​ As such, it can be safely vetoed as impractical. ​ The next section assumes we are talking about Stas's original proposal, which is to allow this syntax: The second way is going to be a terrible headache for all OO authors, past and present, and will prevent migration to PHP 5.3 for those who are only looking for security fixes and performance improvements. ​ As such, it can be safely vetoed as impractical. ​ The next section assumes we are talking about Stas's original proposal, which is to allow this syntax:
Line 170: Line 171:
  
   * if classname->​method() is used, it solves the ambiguity issue   * if classname->​method() is used, it solves the ambiguity issue
 +  * Definitely the smallest codebase change
  
 ==== Problems ==== ==== Problems ====
Line 179: Line 181:
   * it redefines a long-established definition of ->, which is not necessarily a problem, but could be confusing for both existing and new users   * it redefines a long-established definition of ->, which is not necessarily a problem, but could be confusing for both existing and new users
   * only educated users would ever think to look for -> unless a massive PR campaign is mounted, which would also make PHP look disorganized. ​ This is simply a political and NOT a technical problem.   * only educated users would ever think to look for -> unless a massive PR campaign is mounted, which would also make PHP look disorganized. ​ This is simply a political and NOT a technical problem.
 +  * does not solve the deeper problems inherent in ::
  
 ===== Use \ as namespace separator ===== ===== Use \ as namespace separator =====
Line 284: Line 287:
   * because \ is a single keystroke, it is possible to require \ prefix for all global functions/​classes/​constants,​ and conversion is minimally effortful (from personal experience trying to convert files to several namespace separators to see what it was like)   * because \ is a single keystroke, it is possible to require \ prefix for all global functions/​classes/​constants,​ and conversion is minimally effortful (from personal experience trying to convert files to several namespace separators to see what it was like)
   * code review ambiguities disappear permanently   * code review ambiguities disappear permanently
-  * name resolution order problems disappear if we decide that "foo/bar" or "​foo::​bar"​ is always prefixed with namespace name, and only short names like "​bar()"​ or "new bar" are checked for both "​nsname/bar()" and internal function "​bar()"​ or "class nsname/bar" and internal class "​bar"​. ​ "/foo/bar" is used for global scoping.+  * name resolution order problems disappear if we decide that "foo\bar" or "​foo::​bar"​ is always prefixed with namespace name, and only short names like "​bar()"​ or "new bar" are checked for both "​nsname\bar()" and internal function "​bar()"​ or "class nsname\bar" and internal class "​bar"​. ​ "\foo\bar" is used for global scoping.
   * code coverage of namespace-related code is so good, it is possible to be very confident of the correctness of the patch.   * code coverage of namespace-related code is so good, it is possible to be very confident of the correctness of the patch.
  
Line 309: Line 312:
 ===== Changelog ===== ===== Changelog =====
  
 + * 1.1: Correct mis-representation of Lukas'​s understanding of Classname->​method()
  
rfc/backslashnamespaces.txt · Last modified: 2017/09/22 13:28 (external edit)