rfc:namespaceresolution

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:namespaceresolution [2008/10/30 10:51] – created lsmithrfc:namespaceresolution [2008/10/30 12:00] – lsmith
Line 1: Line 1:
-====== Request for Comments: How to write RFCs ======+====== Namespace identifier resolution RFC ======
   * Version: 0.9   * Version: 0.9
   * Date: 2008-10-30   * Date: 2008-10-30
Line 14: Line 14:
 ==== Why do we need RFCs? ==== ==== Why do we need RFCs? ====
  
-Obviously its important that we make a conscious decision for these questions. Depending on how we approach this, users might unintentionally trigger __autoload(), call functions in the global namespace they did not expect or they could run into trouble when trying to migrate existing code to namespaces.+Obviously its important that we make a conscious decision for these questions. Depending on how we approach this, users might unintentionally trigger autoload, call functions in the global namespace they did not expect or they could run into trouble when trying to migrate existing code to namespaces.
  
 ===== Possible approaches ===== ===== Possible approaches =====
Line 27: Line 27:
 In the past people created classes often for the sole reason of being able to sort of "namespace" their functions. Given that we now have real namespaces, class usage as a namespace replacement is no longer necessary. Still another possible assumption, which is considerably more dangerous to make, would be that most code that uses namespaces will mostly use classes inside the current namespace. In the past people created classes often for the sole reason of being able to sort of "namespace" their functions. Given that we now have real namespaces, class usage as a namespace replacement is no longer necessary. Still another possible assumption, which is considerably more dangerous to make, would be that most code that uses namespaces will mostly use classes inside the current namespace.
  
-One noteworthy aspect here is that for classes we have __autoload(). If non fully qualified identifiers can be used to reference global identifiers, "lazy" programmers can skip fully qualifying identifiers even if they have the full intention of referencing a global identifier. With __autoload() this could trigger expensive operations, which are essentially useless.+One noteworthy aspect here is that for classes we have autoload. If non fully qualified identifiers can be used to reference global identifiers, "lazy" programmers can skip fully qualifying identifiers even if they have the full intention of referencing a global identifier. With autoload this could trigger expensive operations, which are essentially useless.
  
-For functions however we do not have __autoload() capabilities. This brings the advantage that falling back to the global namespace does not run the performance risk of __autoload(). So a fallback would be much less expensive, but obviously there would still be overhead for not making intentional references to the global namespace fully qualified.+For functions however we do not have autoload capabilities. This brings the advantage that falling back to the global namespace does not run the performance risk of autoload. So a fallback would be much less expensive, but obviously there would still be overhead for not making intentional references to the global namespace fully qualified.
  
 At the same time the ability to automatically fallback into the global namespace gives the ability to overload global identifiers inside a namespace without having to modify existing code inside that namespace. This however can also be considered dangerously similar to the ambiguity issues we solved by changing the namespace separator. Static code analysis becomes more difficult, which is always the cost of overloading. At the same time the ability to automatically fallback into the global namespace gives the ability to overload global identifiers inside a namespace without having to modify existing code inside that namespace. This however can also be considered dangerously similar to the ambiguity issues we solved by changing the namespace separator. Static code analysis becomes more difficult, which is always the cost of overloading.
  
-Further more users need to be aware that if they are overloading internal identifiers that they to make sure that either the relevant code is loaded. For classes there is the __autoload() approach would would ensure that the class to overload is loaded on demand if necessary. Users that do not use __autoload() or that are overloading function (and constants) run the risk of their code behaving differently in not so obvious ways if they do not always flat out load all files defining relevant functions (and constants) for this namespace.+Further more users need to be aware that if they are overloading internal identifiers that they to make sure that either the relevant code is loaded. For classes there is the autoload approach would would ensure that the class to overload is loaded on demand if necessary. Users that do not use autoload or that are overloading function (and constants) run the risk of their code behaving differently in not so obvious ways if they do not always flat out load all files defining relevant functions (and constants) for this namespace.
  
 One approach to make it at least noticeable when a fallback into the global namespace occurs would be to for example throw an E_NOTICE. This would obviously discourage users from using the fallback for overloading, but it would ensure that people migrating legacy code or people who have not yet fully understood namespaces, would be able to find out about where they are loosing performance. One approach to make it at least noticeable when a fallback into the global namespace occurs would be to for example throw an E_NOTICE. This would obviously discourage users from using the fallback for overloading, but it would ensure that people migrating legacy code or people who have not yet fully understood namespaces, would be able to find out about where they are loosing performance.
Line 56: Line 56:
 == Advantages == == Advantages ==
   - Does not require fully qualified names for functions (and constants)   - Does not require fully qualified names for functions (and constants)
-  - No performance "bomb" with __autoload()+  - No performance "bomb" with autoload
   - Ability to overload global functions (and constants)   - Ability to overload global functions (and constants)
  
Line 76: Line 76:
 == Disadvantages == == Disadvantages ==
   - Functions (and constants) still need fully qualified names   - Functions (and constants) still need fully qualified names
-  - Possible performance bomb with __autoload()+  - Possible performance bomb with autoload
  
 === Only for internal identifiers === === Only for internal identifiers ===
Line 106: Line 106:
 == Disadvantages == == Disadvantages ==
   - There is overhead for the fallback   - There is overhead for the fallback
-  - Additionally there is a possible performance bomb with __autoload()+  - Additionally there is a possible performance bomb with autoload
   - Overloading global identifiers requires ensuring that all relevant files are loaded or unexpected behavior might occur   - Overloading global identifiers requires ensuring that all relevant files are loaded or unexpected behavior might occur
  
Line 119: Line 119:
   - Require fully qualified names for all global identifiers   - Require fully qualified names for all global identifiers
  
-==== More about RFCs ====+==== More about namespaces ====
  
-http://en.wikipedia.org/wiki/Request_for_Comments+http://wiki.php.net/rfc/backslashnamespaces
  
 ===== Changelog ===== ===== Changelog =====
rfc/namespaceresolution.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1

Page Tools