rfc:namespaceissues

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:namespaceissues [2008/10/15 20:28] – cellogrfc:namespaceissues [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== Request for Comments: Namespace Issues and Greg's Solutions ====== ====== Request for Comments: Namespace Issues and Greg's Solutions ======
-  * Version: 1.0+  * Version: 1.1.1
   * Date: 2008-10-15   * Date: 2008-10-15
   * Author: Greg Beaver <cellog@php.net>   * Author: Greg Beaver <cellog@php.net>
Line 15: Line 15:
   1. conflict between namespaced functions and static class methods   1. conflict between namespaced functions and static class methods
   2. resolving access to internal classes   2. resolving access to internal classes
 +
 +Contrary to the doom and gloom on php-internals, there is no technical barrier to implementing namespaces properly.  There is, however, a substantial political barrier.  The internals developers who are namespace experts do not agree on the priorities for namespaces, and this is the only reason nothing has been committed.  I strongly disagree with the contention that namespaces are flawed.  One need only use them to see that they work just fine, except for a few rare edge cases.
 +
 +My interest in this document is simply to point out the only remaining issues and how easy it is to solve them.  None of the other solutions proposed (such as re-using -> for staticclass->method()) will work.  Let's be clear: the solutions for problem #1 I am mentioning here are the **only** way to solve the problems that will be manageable and safe.  The solution I mention for problem #2 is also the only way to safely solve the problem, although it does introduce some extra work to use internal classes.
  
 ===== Conflict between namespaced functions and static class methods ===== ===== Conflict between namespaced functions and static class methods =====
Line 41: Line 45:
 one::step::two(); one::step::two();
 </code> </code>
 +
  
 ==== The solutions ==== ==== The solutions ====
Line 59: Line 64:
  
      If the "use" statement is missing, an E_WARNING should also be thrown to alert the user to the ambiguity      If the "use" statement is missing, an E_WARNING should also be thrown to alert the user to the ambiguity
 +
 +     Note that existing code relying upon "use" statements would work unchanged - the only change needed would be in the case of
 +     a naming conflict.
   4. disallow mixing namespaces and classes with the same name   4. disallow mixing namespaces and classes with the same name
 +
 +I prefer #2, but would be happy with #3 or #1.
  
 ==== use ::: as primary namespace separator ==== ==== use ::: as primary namespace separator ====
Line 179: Line 189:
 This will be better for 99% of scripts, as evidenced by the ratio of internal vs. userspace classes (see http://marc.info/?l=php-internals&m=122127176407546&w=2 for detail) This will be better for 99% of scripts, as evidenced by the ratio of internal vs. userspace classes (see http://marc.info/?l=php-internals&m=122127176407546&w=2 for detail)
  
-===== Changelog =====+===== Why Stas's proposed solution doesn't work =====
  
 +[[rfc:namespaceref#namespaces_with_functionsconstants|Stas's proposed solution]] suggests:
  
 +> New syntax for static access is introduced: using ''Name->Member'' is the same as ''Name::Member'', e.g.:
 +<code>
 +ClassName->Foo() - static method call
 +ClassName->$Foo - static property access
 +ClassName->Foo - class constant access
 +</code>
 +
 +Although this would in theory solve the ambiguity, it does not solve the ambiguity for all existing code, which as we know uses this syntax:
 +
 +<code php>
 +<?php
 +ClassName::Foo();
 +?>
 +</code>
 +
 +In fact, this proposal would require every single reference to a static method or class constant to be rewritten as ClassName->Foo(), a major shift in the language.  Inertia will prevent PHP developers from doing this, just as it has for all other quick fixes introduced.  For example, many PHP projects circumvented the need to rewrite code that relied upon register_globals by simply importing $_GET and $_POST into the global space, introducing a whole new host of security issues that Stefan Esser and others have repeatedly ranted about with good reason.
 +
 +The only fixes that can solve the problem are fixes that do **not** force PHP developers to rewrite code.  Every proposal below would only require changes to as-yet-unwritten code.  Solution #3 would in fact not even require changes to code written based on PHP 5.3alpha2.  Solution #1 and #2 would require code based on PHP 5.3alpha2 namespaces to be modified, and Solution #4 may require re-factoring of code if namespaces and classes share the same name.
 +
 +===== Changelog =====
  
 +  * Version 1.1: add [[#why_stas_s_proposed_solution_doesn_t_work|new section]] to explain why ClassName->Blah fails to solve the problem
 +  * Version 1.1.1: move Classname->Blah to bottom of proposal for reading flow
rfc/namespaceissues.1224102509.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools