rfc:namespaces

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:namespaces [2008/09/15 23:23] – tweak jochemrfc:namespaces [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 108: Line 108:
 <code> <code>
 defined('DEBUG'): YES (expect YES) defined('DEBUG'): YES (expect YES)
-defined('my::test::ns::DEBUG_2'): NO (expect YES)+defined('MY::TEST::NS::DEBUG_2'): NO (expect YES)
 defined('my::test::ns::DEBUG_2'): NO (expect NO) defined('my::test::ns::DEBUG_2'): NO (expect NO)
 defined('my::test::ns::debug_2'): NO (expect NO) defined('my::test::ns::debug_2'): NO (expect NO)
Line 488: Line 488:
 There is no way to reference the static method **TEST::what()**, additionally because static method **TEST::where()** is reachable one is left with the potential that the namespaced include will break current code if a **where()** function is later defined in the **TEST** namespace.  There is no way to reference the static method **TEST::what()**, additionally because static method **TEST::where()** is reachable one is left with the potential that the namespaced include will break current code if a **where()** function is later defined in the **TEST** namespace. 
  
-//There is a need to disambiguate these two calls, and to be able to call both regardless of the existence of either one.// +//There is a need to disambiguate these two calls, and to be able to call both regardless of the existence of the other.// 
-  +
 ---- ----
  
 ==== 7. Class constants v. constants ambiguities ==== ==== 7. Class constants v. constants ambiguities ====
 +The same ambiguity that exists between static methods and namespaced functions also exists between class constants and namespaced constants.  
 +From the users point of view it not possible to determine, with any easy or certainty, from the code whether **TEST::MY_CONST_ONE** (from example1.php below) is a class constant or a namespaced constant. The statement could, in this case, be either, and which ever it is the other has been rendered unusable, the code below demonstrates:
 +
 +class.inc:
 +<code php>
 +<?php
 +class TEST {
 +    const MY_CNST_ONE = 'TEST class CONSTANT ONE';
 +    const MY_CNST_TWO = 'TEST class CONSTANT TWO';
 +}
 +?>
 +</code>
 +
 +ns.inc:
 +<code php>
 +<?php
 +namespace TEST;
 +const MY_CNST_ONE = 'TEST class CONSTANT ONE';
 +?>
 +
 +example1.php:
 +<code php>
 +<?php
 +include './class.inc';
 +include './ns.inc';
 +echo TEST::MY_CNST_ONE, "\n";
 +echo TEST::MY_CNST_TWO, "\n";
 +?>
 +</code>
 +
 +output of example1.php (regardless of include order):
 +<code>
 +TEST namespace CONSTANT ONE
 +TEST class CONSTANT TWO
 +</code>
 +
 +There is no way to reference the constant **MY_CNST_ONE** from class **TEST**, additionally because constant **MY_CNST_TWO** from class **TEST** is reachable one is left with the potential that the namespaced include will break current code if a constant **MY_CNST_TWO** is later defined in the TEST namespace, regardless it introduces confusion because one is it possible to retrieve constants from two different 'places' using the exact same prefix/syntax.
  
 +//There is a need to disambiguate the constants, and to be able to reference both regardless of the existence of the other.// 
  
  
Line 720: Line 758:
 > >
 > If a fully qualified name is prefixed with function:: or const:: it will only check the namespace function/const.  Here is a test demonstrating how it works: > If a fully qualified name is prefixed with function:: or const:: it will only check the namespace function/const.  Here is a test demonstrating how it works:
- +> 
-ns_071.inc: +> ns_071.inc: 
-<code php>+> <code php>
 <?php <?php
 namespace foo; namespace foo;
Line 735: Line 773:
 ?> ?>
 </code> </code>
-ns_071.phpt: +> ns_071.phpt: 
-<code php>+> <code php>
 --TEST-- --TEST--
 071: name conflict, function/static method, constant/class constant 071: name conflict, function/static method, constant/class constant
Line 777: Line 815:
 This patch addresses the inability to include [html] output prior to the first **<?php** tag, in a namespaced file, as defined in **issue 12. "Namespace must be first declaration in file"**   This patch addresses the inability to include [html] output prior to the first **<?php** tag, in a namespaced file, as defined in **issue 12. "Namespace must be first declaration in file"**  
  
 +To quote the author from his original post regarding this patch: 
  
 +> This is a simple patch that allows files like this to work without parse error.:
 +> 
 +> main.php:
 +> <code php>
 +<html>
 +<head>
 +<title>template example</title>
 +</head>
 +<body>
 +<?php
 +namespace my::template;
 + 
 +// stuff
 +
 +?>
 +</body>
 +</html>
 +</code>
  
 ===== Miscellaneous ===== ===== Miscellaneous =====
Line 819: Line 876:
   * [[php-internals@119874502923978|Suggestion: Namespace implementation]]   * [[php-internals@119874502923978|Suggestion: Namespace implementation]]
  
-Nothing has been filtered on the basis of relevance!+//Nothing has been filtered on the basis of relevance BUT some threads may not be listed due to the 'limitations' of the marc.info search functionality!//
  
  
rfc/namespaces.1221520985.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools