rfc:changes_to_include_and_require

Differences

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

Link to this comparison view

Next revision
Previous revision
rfc:changes_to_include_and_require [2012/03/06 16:01] – created michaelmorrisrfc:changes_to_include_and_require [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
-====== Request for Comments: Additional Parameters to Include and Require ======+====== Request for Comments: Additional Parameter for Include and Require ======
   * Version: 0.1   * Version: 0.1
   * Date: 2012-03-06   * Date: 2012-03-06
Line 9: Line 9:
 ===== Introduction ===== ===== Introduction =====
  
-Proposed are a pair of changes to the file inclusion process, and the four language statements that process those includes - include, include_once, requireand require_once. The changes can be implemented together or independently.  Throughout this RFC include is mentioned directly, but wherever it is mentioned the change applies to the other three.+Change include, include_once, require and require_once to take a second optional string argument.
  
 +require( 'path/to/file.php', ['namespace\to\attach\file'] );
  
-===== Tagless Files ===== +Currently files are always imported to the root namespace.  The suggested change is to allow a namespace to be passed as the second argument to include. If a namespace is specified then the file is imported to that namespace. If the file has a namespace definition that namespace becomes a sub-namespace when imported.  If no namespace is specified the backward compatible behavior of attaching the file to the root namespace occurs.
- +
-A common beginner gotcha occurs the first time they attempt to use sessions or the header function. Whitespace outside the php tags is sent to the browser, and the first time this occurs its too late to start a session or make changes to the file header, so a warning is output. +
- +
-This could be avoided if a PHP file could be written and accepted without an opening <?php tag (the closing tag can be omitted without affecting the parser - whether it should be is up for debate).  For this to be possible PHP needs to be warned that this is going to occur. So a boolean argument is added to the include call.  If not passed, or 'false' the legacy behavior of expecting a <?php tag to be in the file will be retained. +
- +
-If 'true' is passed then the code is presumed to be PHP, at least until a closing tag is encountered. +
- +
-Framework designers can more strongly enforce code separation. For example, if a coder attempts to jump to html output in what the framework expects to be a database interface class - which shouldn't need to output html - there would be a syntax crash caused by this. Again the obstinate coder could work around this with echo. +
- +
-===Questions=== +
-Is it worth the time to enforce the whole file be tag less?  I would imagine on the implementation side doing what is discussed above would be as simple as appending "<?php" to the start of the text stream of the file, then let the parser proceed as normal.  Also, echoing output would still be possible.  +
- +
-Would the engine run faster if it could parse the file without worrying about the <?php ?> tokens at all? Would the pickup be worth the time? +
- +
-===Problems=== +
-The largest problem is with IDE's. There is no current convention to warn them that the file is pure PHP.  However, I think this can be mitigated by adopting an extension for php include files -- *.pif, *.iphp are two possibilities.  However, the language itself doesn't need to give a care about this directly. +
- +
-An addendum to this problem is the possibility of having PHP parse the file differently dependent on the extension.  This is strictly speaking a BC break, but I don't imagine the scope would be large. Maybe a ini file extension to turn on tag less parsing for the listed extensions? +
- +
- +
-===== Defining Namespace on Inclusion ===== +
- +
-Currently files are always imported to the root namespace.  The second suggestion is to allow a namespace to be passed as an argument to include. If a +
-namespace is specified then the file is imported to that namespace. If the file has a namespace definition that namespace becomes a sub-namespace when imported.+
  
 The lesser use of this change is to allow php template files to not have to start with a namespace declaration. Since these files are meant to be used by designers the namespace declaration, which is business logic, feels out of place.  The lesser use of this change is to allow php template files to not have to start with a namespace declaration. Since these files are meant to be used by designers the namespace declaration, which is business logic, feels out of place. 
Line 53: Line 30:
  
 This provides a powerful layer of flexibility for frameworks.  It also allows a tyro to whack their foot off and spaghetti doesn't even begin to describe the situation that will occur if this gets used incorrectly. This provides a powerful layer of flexibility for frameworks.  It also allows a tyro to whack their foot off and spaghetti doesn't even begin to describe the situation that will occur if this gets used incorrectly.
 +
 +===== Questions =====
 +
 +1)
 +Is it not possible that the library being pulled contains references to itself in the original namespace, rather than the new sub-namespace the require/include is forcing upon it?
 +
 +Or do you anticipate that all such references would be converted?
 +
 +What if, somehow, the library composes the reference from $data rather than hard-coded? (Which might be kind of crazy, but you know those PHP guys...)
 +
 +2) Add more questions.
  
 ===== Changelog ===== ===== Changelog =====
  
 2012-03-06 - Initial proposal. 2012-03-06 - Initial proposal.
 +2012-03-08 - Dropped one of the pair after negative reception on the list to concentrate on the second.
rfc/changes_to_include_and_require.1331049660.txt.gz · Last modified: 2017/09/22 13:28 (external edit)