rfc:source_files_without_opening_tag
no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
Previous revisionNext revision | |||
— | rfc:source_files_without_opening_tag [2012/04/10 23:45] – [Why is this desirable?] boutell | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Request for Comments: Source Files Without Opening Tag ====== | ||
+ | * Version: 1.1 | ||
+ | * Date: 2012-04-10 | ||
+ | * Author: Thomas Boutell < | ||
+ | * Status: Under Discussion | ||
+ | * First Published at: http:// | ||
+ | * Other formats: none yet | ||
+ | |||
+ | This RFC proposes a way to support source code files without ''<? | ||
+ | |||
+ | ===== Introduction ===== | ||
+ | |||
+ | The purpose of this RFC is to provide a way to support source files that do not begin with ''<? | ||
+ | |||
+ | ==== Why is this desirable? ==== | ||
+ | |||
+ | In modern framework development and larger projects in general, it is often considered good practice to implement PHP classes in files which contain only | ||
+ | PHP code. If methods of such classes do have a desire for HTML templating, they accomplish it by requiring a separate template file. In such "pure code" files, typing ''<? | ||
+ | |||
+ | 1. Error-prone in a subtle and hard-to-debug way: if any whitespace is introduced before ''<? | ||
+ | |||
+ | 2. Tedious. There is a small but real frustration involved in this redundancy. Small but real frustrations can contribute to long-term disenchantment with a programming language. | ||
+ | |||
+ | However these same projects and frameworks may advocate the use of "raw HTML" in PHP files intended as templates for rendering pages, forms and the like. This is a longstanding feature of PHP (indeed the original feature of PHP). Support for it should be maintained, and may perhaps be improved in future to address PHP's current limitations as a templating language. The two modes should not be mutually exclusive as this makes it impossible for code to interoperate. This proposal aims not to close any doors in this regard. | ||
+ | |||
+ | ==== Related RFC ==== | ||
+ | |||
+ | - [[rfc: | ||
+ | |||
+ | ===== Proposal ===== | ||
+ | |||
+ | === Part 1: Enhance the include, include_once, | ||
+ | |||
+ | These keywords will be enhanced with a second, optional parameter. | ||
+ | |||
+ | The first parameter (the URL/ | ||
+ | |||
+ | The second parameter is a combination of integer flags, combined in the usual way with the OR operator ('' | ||
+ | |||
+ | If this second parameter is absent, the four keywords behave exactly as they do now. | ||
+ | |||
+ | When the second parameter is present, it may be a bitwise OR of zero or more of the following constants which add to (but never subtract from) the existing behavior of each keyword: | ||
+ | |||
+ | If '' | ||
+ | |||
+ | If '' | ||
+ | |||
+ | If '' | ||
+ | |||
+ | Examples: | ||
+ | |||
+ | // Absolutely no change to existing behavior | ||
+ | require ' | ||
+ | | ||
+ | // Load filename.phpp. This file must consist purely of source code, no <?php or ?> tokens needed or permitted | ||
+ | require ' | ||
+ | |||
+ | // Behaves just like include_once | ||
+ | include ' | ||
+ | |||
+ | // Behaves just like require | ||
+ | include ' | ||
+ | |||
+ | // Combine them all: includes only once, with a fatal error on failure, parsing in "code mode" | ||
+ | include ' | ||
+ | |||
+ | // Exactly the same as previous example | ||
+ | require_once ' | ||
+ | | ||
+ | === Part 2: Filename Convention === | ||
+ | |||
+ | Although this proposal gives implementers flexibility in when and where they use the INCLUDE_PURE_CODE bit, it is still desirable in most cases to have a commonly recognized convention to distinguish files that should be read starting in "PHP mode" from legacy and template files that should be read starting in "HTML mode." The following convention is proposed for environments in which file extensions are a relevant and useful concept: | ||
+ | |||
+ | * Files that should be read starting in HTML mode should have a '' | ||
+ | * Files that should be read starting in PHP mode should have a '' | ||
+ | |||
+ | However enforcement of this convention is NOT proposed. The choice to apply '' | ||
+ | |||
+ | ===== Anticipated And Previously Raised Questions ===== | ||
+ | |||
+ | (Thanks to those who raised and responded to some of these questions already on the internals list. I am summarizing in many cases.) | ||
+ | |||
+ | **" | ||
+ | |||
+ | No. Code that never uses the new keyword will not be affected in any way. The proposal allows autoloaders to load files the old-fashioned way and to recognize when to do so by a simple common convention or by other local conventions as appropriate. | ||
+ | |||
+ | **" | ||
+ | |||
+ | Typically projects that will benefit from this flag also have autoloaders to load classes implicitly when they are first used. So '' | ||
+ | |||
+ | **" | ||
+ | |||
+ | Not really. Even in a worst-case scenario where '' | ||
+ | |||
+ | **" | ||
+ | |||
+ | Of course. A choice to use this feature implies a choice to support only the supporting version of PHP or newer. But it'll break cleanly with a clear error message, just like code that tries to use traits or other newer features. | ||
+ | |||
+ | **"Why does the proposal forbid the use of ''?>'' | ||
+ | |||
+ | The first version of the proposal did permit this as a compromise. However it did not please anyone. Those who want to write "pure PHP" class files are not interested in switching from code to markup in the middle of a method and are still able to '' | ||
+ | |||
+ | **"Why not introduce a new keyword rather than enhancing four keywords?" | ||
+ | |||
+ | A new keyword was proposed and did not go over well. Enhancing the existing keywords, allowing their existing behavior to automatically switch on some of the flag bits, turns out to be both more elegant and more familiar. | ||
+ | |||
+ | **"Why three flags instead of one? Aren't the other two redundant?" | ||
+ | |||
+ | While the '' | ||
+ | |||
+ | **"Why bitwise flags instead of an associative array of options?" | ||
+ | |||
+ | Bitwise flags are faster and also provide built-in error checking: use of a constant not defined by a particular version of PHP will generate a notice. Require statements are something PHP executes quite often, so generating unnecessary arrays and testing array values is an unnecessary performance hit. | ||
+ | |||
+ | ===== Changelog ===== | ||
+ | |||
+ | * 2011-04-09 Yasuo Ohgaki: Added related RFC. | ||
+ | * 2011-04-10 Thomas Boutell: removed misleading word " | ||
+ | * 2011-04-10 Thomas Boutell: version 1.1. Replaced '' | ||
+ | |||
rfc/source_files_without_opening_tag.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1