rfc:backslashnamespaces

Differences

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

Link to this comparison view

Next revision		Previous revision
Next revisionBoth sides next revision
rfc:backslashnamespaces [2008/10/25 06:32] – created cellogrfc:backslashnamespaces [2008/10/25 13:54] – fix error in Lukas's understanding of Classname->method() cellog
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_DEPRECATED) for :: 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 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 by 127.0.0.1

Page Tools