# RFC: source files without opening tag - Thread: https://externals.io/message/59466 - Original archive: https://news-web.php.net/php.internals/59466 - Started by Tom Boutell on 2012-04-08T16:32:23+00:00 - Messages: 62 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/59466.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #59466 — Tom Boutell — 2012-04-08T16:32:23+00:00 URL: https://externals.io/message/59466#59466 I have written an RFC proposing backwards-compatible support for source files without an opening I have written an RFC proposing backwards-compatible support for > source files without an opening > https://wiki.php.net/rfc/source_files_without_opening_tag > > This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure > what the requirements are to get it added to the "Under Discussion" > session and get the ball rolling formally. Please enlighten and I'll > do whatever is required. > > Thanks! > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com --- ## #59474 — Tom Boutell — 2012-04-08T21:25:08+00:00 URL: https://externals.io/message/59466#59474 · In reply to: #59472 I don't think I have the privilege of editing the main page that lists all the RFCs. The template should probably say "In Draft" rather than starting out with the wrong status (: > As far as I know, you've already met that req by posting the RFC here, so go > ahead and add it.  In the future, remember there's also an "In Draft" status > for RFCs that haven't been announced here yet.  :) > > > > […] > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com --- ## #59476 — Yasuo Ohgaki — 2012-04-08T21:49:43+00:00 URL: https://externals.io/message/59466#59476 · In reply to: #59466 Hi, Moriyoshi has created same entry on 4/1, but it seems it was deleted already. Anyway, he had a patch for it. https://gist.github.com/2266652 As I mentioned in other thread, we should better to have a switch to disable embed mode for security reasons. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net 2012/4/9 Tom Boutell : > I have written an RFC proposing backwards-compatible support for > source files without an opening > https://wiki.php.net/rfc/source_files_without_opening_tag > > This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure > what the requirements are to get it added to the "Under Discussion" > session and get the ball rolling formally. Please enlighten and I'll > do whatever is required. > > Thanks! > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com --- ## #59477 — Yasuo Ohgaki — 2012-04-08T21:55:28+00:00 URL: https://externals.io/message/59466#59477 · In reply to: #59476 Hi, There is RFC that is written by Moriyoshi. It's not listed in RFC page, though. https://wiki.php.net/rfc/nophptags I think these should be merged. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net 2012/4/9 Yasuo Ohgaki : > Hi, > > Moriyoshi has created same entry on 4/1, but > it seems it was deleted  already. > > Anyway, he had a patch for it. > > https://gist.github.com/2266652 > > As I mentioned in other thread, we should better to have > a switch to disable embed mode for security reasons. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > > > > 2012/4/9 Tom Boutell : > > […] --- ## #59479 — Tom Boutell — 2012-04-08T22:20:20+00:00 URL: https://externals.io/message/59466#59479 · In reply to: #59477 Moriyoshi was kidding, as near as I can tell (: To take it at face value though, the *cough* April 1st *cough* proposal of Moriyoshi calls for the complete abolition of the feature with no backwards compatibility with existing code that uses PHP as a template language... including most popular frameworks that sensibly obey a separation between class files and template files but still use PHP rather than a dedicated templating language for templates. I don't think that's realistic (and neither did the author it appears). Since PHP's usability as a template language may conceivably be improved by other proposals, it is undesirable as well even if you don't currently find PHP to be a suitable template language. Please read my proposal over carefully as it does address the obvious issues that make Moriyoshi's proposal possibly less than serious in intent (: I would oppose a php.ini flag for this as that gives us two incompatible versions of the current version of the language to worry about and makes the feature effectively unusable in reusable code. This approach has created problems before. > Hi, > > There is RFC that is written by Moriyoshi. > It's not listed in RFC page, though. > > https://wiki.php.net/rfc/nophptags > > I think these should be merged. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > > > > 2012/4/9 Yasuo Ohgaki : > > […] -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com --- ## #59480 — Yasuo Ohgaki — 2012-04-08T22:45:48+00:00 URL: https://externals.io/message/59466#59480 · In reply to: #59479 Hi, I talked on twitter. Yes, he is kidding, but he is serious, too. I've added the RFC to Under Discussion and added security issue description. I also added my proposal that controls embed mode. BTW, I don't think we need new "require_path" why don't we use require "file.php", ture; or some thing similar? I prefer to use switch, since security countermeasure is better to be enforced by switch. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net 2012/4/9 Tom Boutell : > Moriyoshi was kidding, as near as I can tell (: > > To take it at face value though, the *cough* April 1st *cough* > proposal of Moriyoshi calls for the complete abolition of the feature > with no backwards compatibility with existing code that uses PHP as a > template language... including most popular frameworks that sensibly > obey a separation between class files and template files but still use > PHP rather than a dedicated templating language for templates. > > I don't think that's realistic (and neither did the author it > appears). Since PHP's usability as a template language may conceivably > be improved by other proposals, it is undesirable as well even if you > don't currently find PHP to be a suitable template language. > > Please read my proposal over carefully as it does address the obvious > issues that make Moriyoshi's proposal possibly less than serious in > intent (: > > I would oppose a php.ini flag for this as that gives us two > incompatible versions of the current version of the language to worry > about and makes the feature effectively unusable in reusable code. > This approach has created problems before. > > > > […] > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com --- ## #59481 — Tom Boutell — 2012-04-08T23:14:08+00:00 URL: https://externals.io/message/59466#59481 · In reply to: #59480 Thanks. However, would you please fix the summary on the RFC's page to match the summary in the actual RFC? As you have written it, it implies that support for Hi, > > I talked on twitter. > Yes, he is kidding, but he is serious, too. > > I've added the RFC to Under Discussion and added > security issue description. I also added my proposal that > controls embed mode. > > BTW, I don't think we need new "require_path" why don't > we use > > require "file.php", ture; > > or some thing similar? > I prefer to use switch, since security countermeasure is > better to be enforced by switch. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > > > > 2012/4/9 Tom Boutell : > > […] -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com --- ## #59482 — Kris Craig — 2012-04-09T05:16:55+00:00 URL: https://externals.io/message/59466#59482 · In reply to: #59481 Tom, > Thanks. However, would you please fix the summary on the RFC's page to > match the summary in the actual RFC? As you have written it, it > implies that support for not the case. > > As for adding a boolean parameter to the require keyword, as the RFC > mentions there are already at least two distinctions already when > requiring files in PHP: > > * include vs. require behavior (warning vs. error on failure) > * once vs. every time (require_once vs. require) > > And we are proposing a third: > > * start in php mode vs. start in html mode > > We already have four keywords for requiring files. At this point it > does not make sense to keep introducing more keywords (we would need 8 > with this change). Your boolean flag proposal keeps it to four > keywords, but as soon as someone adds another flag it will become > awkward to remember them. Since PHP does not have named parameters I > think an associative array is the best way to go (especially with the > new short syntax). > > Also I don't think it makes sense to forbid shifting into html mode > later in the file, it could reduce support for the proposal needlessly > - since it already lets people who want to write clean all-PHP files > do so, and some of those people might have legitimate reasons to use > HTML mode in the scope of a function or method (where it does not > suddenly introduce whitespace without being explicitly called, etc). > > But if it really came down to it I could live with an "absolutely > nothing but PHP" behavior when the code flag is true (supporting when the flag is not set is a must of course). > > > > […] > wrote: > > […] > sure > > […] > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- > > > > I think this is a great idea overall, but it seems to me as though we're needlessly over-complicating things. If we just go with a separate file extension for pure PHP code (i.e. everything in the file is parsed as if it was contained in a tag would throw an error), then there's no need for adding new keywords or INI flags. If a pure PHP file includes a regular PHP file that contains HTML, a warning would be thrown and anything not within the * include vs. require behavior (warning vs. error on failure) > * once vs. every time (require_once vs. require) > > And we are proposing a third: Then, better name would be require_script()/include_script(). However, this option will not solve script inclusion security issues. Fixing security issues will not have much opposition, but adding new syntax will. I like embedded languages, but programmers can write vulnerable code with it. Embed feature is better to be controlled by programmers/ administrators for better security. Regards, P.S. I'm uncomfortable with current PHP, since someone may write "include $_GET['module']" or like for my systems. This code raises fatal security issue with current PHP, but it's not with my proposal. -- Yasuo Ohgaki yohgaki@ohgaki.net 2012/4/9 Tom Boutell : > Thanks. However, would you please fix the summary on the RFC's page to > match the summary in the actual RFC? As you have written it, it > implies that support for not the case. > > As for adding a boolean parameter to the require keyword, as the RFC > mentions there are already at least two distinctions already when > requiring files in PHP: > > * include vs. require behavior (warning vs. error on failure) > * once vs. every time (require_once vs. require) > > And we are proposing a third: > > * start in php mode vs. start in html mode > > We already have four keywords for requiring files. At this point it > does not make sense to keep introducing more keywords (we would need 8 > with this change). Your boolean flag proposal keeps it to four > keywords, but as soon as someone adds another flag it will become > awkward to remember them. Since PHP does not have named parameters I > think an associative array is the best way to go (especially with the > new short syntax). > > Also I don't think it makes sense to forbid shifting into html mode > later in the file, it could reduce support for the proposal needlessly > - since it already lets people who want to write clean all-PHP files > do so, and some of those people might have legitimate reasons to use > HTML mode in the scope of a function or method (where it does not > suddenly introduce whitespace without being explicitly called, etc). > > But if it really came down to it I could live with an "absolutely > nothing but PHP" behavior when the code flag is true (supporting when the flag is not set is a must of course). > > > > […] > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com --- ## #59484 — Yasuo Ohgaki — 2012-04-09T06:17:20+00:00 URL: https://externals.io/message/59466#59484 · In reply to: #59483 Hi Tom, It's better to distinguish security related issue and others. Therefore, I listed Moriyoshi's proposal to RFC list and put my proposal in it. His proposal is almost the same as mine except the flag for embed mode control. https://wiki.php.net/rfc/nophptags I recovered the original except for adding references to No PHP Tags RFC. https://wiki.php.net/rfc/source_files_without_opening_tag This makes discussion more clear to everyone, I hope. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #59496 — Tom Boutell — 2012-04-09T10:55:39+00:00 URL: https://externals.io/message/59466#59496 · In reply to: #59482 .phpp would be fine. .phpp code needs to be able to interoperate with .php templates, otherwise one can't supply reusable libraries that implement generic algorithms without surprises for those who integrate them in older projects. Sent from my iPhone > Tom, > > > Thanks. However, would you please fix the summary on the RFC's page to > match the summary in the actual RFC? As you have written it, it > implies that support for not the case. > > As for adding a boolean parameter to the require keyword, as the RFC > mentions there are already at least two distinctions already when > requiring files in PHP: > > * include vs. require behavior (warning vs. error on failure) > * once vs. every time (require_once vs. require) > > And we are proposing a third: > > * start in php mode vs. start in html mode > > We already have four keywords for requiring files. At this point it > does not make sense to keep introducing more keywords (we would need 8 > with this change). Your boolean flag proposal keeps it to four > keywords, but as soon as someone adds another flag it will become > awkward to remember them. Since PHP does not have named parameters I > think an associative array is the best way to go (especially with the > new short syntax). > > Also I don't think it makes sense to forbid shifting into html mode > later in the file, it could reduce support for the proposal needlessly > - since it already lets people who want to write clean all-PHP files > do so, and some of those people might have legitimate reasons to use > HTML mode in the scope of a function or method (where it does not > suddenly introduce whitespace without being explicitly called, etc). > > But if it really came down to it I could live with an "absolutely > nothing but PHP" behavior when the code flag is true (supporting when the flag is not set is a must of course). > > > > […] > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- > > > > > I think this is a great idea overall, but it seems to me as though we're needlessly over-complicating things. If we just go with a separate file extension for pure PHP code (i.e. everything in the file is parsed as if it was contained in a tag would throw an error), then there's no need for adding new keywords or INI flags. If a pure PHP file includes a regular PHP file that contains HTML, a warning would be thrown and anything not within the > That said, we might want to consider a file extension other than ".phpc". There are some PHP-related projects/commits that already use this file extension for other purposes and could be broken by this. Probably wouldn't be a huge deal but a quick Google search shows that we would be stepping on a few people's toes by going with that extension. > > Instead, how about going with ".phpp" (as-in, "PHP Pure")? A Google search on that shows it's not being used anywhere (except for one blog post from 2007 that linked to a .phpp file, but it looks like he just named it that so that it wouldn't be parsed by the webserver). That way we wouldn't be creating any conflicts with existing applications/projects. =) > > --Kris --- ## #59498 — Tom Boutell — 2012-04-09T10:57:31+00:00 URL: https://externals.io/message/59466#59498 · In reply to: #59484 I think separating these rfcs makes sense, thanks. Sent from my iPhone > Hi Tom, > > It's better to distinguish security related issue and others. > Therefore, I listed Moriyoshi's proposal to RFC list and put > my proposal in it. His proposal is almost the same as mine > except the flag for embed mode control. > > https://wiki.php.net/rfc/nophptags > > I recovered the original except for adding references to No > PHP Tags RFC. > > https://wiki.php.net/rfc/source_files_without_opening_tag > > This makes discussion more clear to everyone, I hope. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net --- ## #59500 — Tom Boutell — 2012-04-09T11:29:09+00:00 URL: https://externals.io/message/59466#59500 · In reply to: #59466 I would like to clarify what this RFC actually says. Let's try to keep this thread to the pros and cons of this specific proposal. The following new keyword would be introduced: require_path This keyword has two parameters of which the second is optional. The first parameter is the path (filename or URL) to be required, and behaves exactly as the sole parameter of the require keyword behaves. The second parameter is an associative array. If this second parameter is absent, require_path behaves exactly like require. If the second parameter is present, the following keys may optionally be present in the array, with the following effects: If 'once' is present and true, the specified path is loaded no more than once, exactly like require_once. If 'warn' is present and true, a loading or compilation error results in `E_WARNING` (per the current behavior of the include keyword). If warn is absent or false, a loading or compilation error results in `E_COMPILE_ERROR` (per the current behavior of the require keyword). If 'code' is present and true, the parser begins reading the file as if a true, 'once' => true); // Loads a file starting out in "PHP mode" so the opening true); In addition, a convention (not a requirement checked by the code) would be encouraged: PHP source code files without an initial > Option 1: Introduce require_path > > I think require_code is a better name.  Parm 1 isn't a path, it is a file, > so require_path seems wrong to me. Yeah, you're not the first to say this. require_file and require_code have both been suggested. I'm fine with either really. > I'd prefer a 'start in code mode' optional second parameter to > include[_once] and require[_once]. That would be fine as far as my goals here go, but I'm concerned that we'll just repeat this discussion if any other options for requiring things come into being (: > Option 2: Filename Convention > > The PHP engine should not know or care what the file extension is.  I won't > object if you can convince autoloader authors to follow the .phpc > convention.  Personally, once I can count on this feature, every file I > include/require will probably be written starting in code mode and using the > new calling convention.  Even when I use PHP to create page templates... Sounds like you're basically OK with that bit. > Additional suggestions: > > Add an option so the CLI can start in code mode too. > > Add another Handler to the Apache SAPI, maybe application/x-httpd-php-code > similar to x-httpd-php and x-httpd-php-source, so we can configure Apache to > start arbitrary file extensions with code mode on.  This defers setting the > action for various file extensions to the person configuring the web server. > > Other web server SAPIs will need similar treatment, but I'll leave them to > someone with personal experience. I'm not opposed to these suggestions. I was trying to keep it conservative and simple to implement and focus on the case where it bugs me (creating libraries of class files), but I'd be happy to see a way for .phpc to be the entry point / frontend controller / standalone script as well. As you say it must be done with SAPI options (the CLI included), not hardcoded file extension checking. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com --- ## #59504 — Crocodile — 2012-04-09T14:02:24+00:00 URL: https://externals.io/message/59466#59504 · In reply to: #59503 IDE creators will definitely be excited with this new feature. 2012/4/9 Tom Boutell > On Mon, Apr 9, 2012 at 9:16 AM, Rick WIdmer > wrote: > > […] > file, > > […] > > Yeah, you're not the first to say this. require_file and require_code > have both been suggested. I'm fine with either really. > > > […] > > That would be fine as far as my goals here go, but I'm concerned that > we'll just repeat this discussion if any other options for requiring > things come into being (: > > > […] > won't > > […] > the > > […] > > Sounds like you're basically OK with that bit. > > > […] > application/x-httpd-php-code > > […] > Apache to > > […] > the > > […] > server. > > […] > to > > […] > > I'm not opposed to these suggestions. I was trying to keep it > conservative and simple to implement and focus on the case where it > bugs me (creating libraries of class files), but I'd be happy to see a > way for .phpc to be the entry point / frontend controller / standalone > script as well. As you say it must be done with SAPI options (the CLI > included), not hardcoded file extension checking. > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com --- ## #59508 — Luke Scott — 2012-04-09T15:43:37+00:00 URL: https://externals.io/message/59466#59508 · In reply to: #59466 Tom, As I've said before I don't think new keywords are the answer. They will just pollute the language even further. I also don't think an ini setting is a bad thing either. It is often used in PHP as a way to transition from way of doing things to another. First you introduce it with it being off by default, then on by default, then deprecate the old behavior. It's quite normal in PHP's history. In another email someone mentioned doing two rfcs. In both cases are we talking about removing tag and treat text before the opening I have written an RFC proposing backwards-compatible support for > source files without an opening > https://wiki.php.net/rfc/source_files_without_opening_tag > > This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure > what the requirements are to get it added to the "Under Discussion" > session and get the ball rolling formally. Please enlighten and I'll > do whatever is required. > > Thanks! > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com --- ## #59515 — Tom Boutell — 2012-04-09T16:16:18+00:00 URL: https://externals.io/message/59466#59515 · In reply to: #59508 It sounds like you are proposing to gradually kill the use of PHP for templating entirely, which I don't think is something people would vote for. I sometimes use perfectly good older frameworks that do use .php files for templating in a reasonable way, and I'm one of the advocates for migrating away from starting everything with Tom, > > As I've said before I don't think new keywords are the answer. They > will just pollute the language even further. > > I also don't think an ini setting is a bad thing either. It is often > used in PHP as a way to transition from way of doing things to > another. First you introduce it with it being off by default, then on > by default, then deprecate the old behavior. It's quite normal in > PHP's history. > > In another email someone mentioned doing two rfcs. In both cases are > we talking about removing confusing to keep track of what is being talked about. If that is the > case, continue reading. > > I would prefer the starting Just explicitly forbid the ending ?> tag and treat text before the > opening or throw an error. > > That is at least how I would prefer the "code" mode as most > non-template files only start with compatibility. > > If you must add keywords it should be something like require_template > NOT require_code/require_file. Templates are the exception, not the > norm. > > Luke Scott > > > > > […] -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com --- ## #59517 — Luke Scott — 2012-04-09T17:10:55+00:00 URL: https://externals.io/message/59466#59517 · In reply to: #59515 > It sounds like you are proposing to gradually kill the use of PHP for > templating entirely, which I don't think is something people would > vote for. I'm not saying that at all. I'm saying that PHP code should be clearly separated from template code. (since PHP 5 due to how easy it is for white space to end up on the tail end of a file). this is even the case with procedural code. Half the PHP frameworks out there have their own template engine because they can do a lot more than what short tags offer. Example: Twig offers template inheritance. Introducing a keyword for PHP code without the and text before the opening I sometimes use perfectly good older frameworks that do use > .php files for templating in a reasonable way, and I'm one of the > advocates for migrating away from starting everything with would have to vote against it myself. And those files can be included with something like require_template or you can turn off the option in the ini file. The point is in EITHER MODE a php file that starts with . > There's no reason to kill good > code that passes its tests just because it uses inline HTML. I won't > even know I have that code in my project from some third party library > until I find out the hard way. No, just no. (: I'm not trying to kill anything. In fact what I'm proposing would be a smooth transition to something that is already done. The difference is at some point you won't be able to do this: Print me! I did propose one new keyword, but by proposing one keyword with a > future-friendly syntax instead of four new keywords I'm attempting to > help with the pollution problem. It's not as much as adding a keyword as it is what keyword you're adding. I hope the way I've explained things makes sense. Luke > > > > […] > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com --- ## #59518 — Tom Boutell — 2012-04-09T17:22:07+00:00 URL: https://externals.io/message/59466#59518 · In reply to: #59517 I see what you're saying, but you're proposing a new keyword to include code that does what plain old 'require' does now (assuming it's not a nice clean class file that is being included). Which means that valid code today is busted code once this feature comes out. That seems like a very hard sell. > > > > […] > > I'm not saying that at all. I'm saying that PHP code should be clearly > separated from template code. the file and IF a keyword should be added it should be for templates > and short-tags. > > 99% of modern PHP code is going to be classes that start with and omit the ending ?> (since PHP 5 due to how easy it is for white > space to end up on the tail end of a file). this is even the case with > procedural code. > > Half the PHP frameworks out there have their own template engine > because they can do a lot more than what short tags offer. Example: > Twig offers template inheritance. > > Introducing a keyword for PHP code without the impractical. It makes much more sense to have a keyword for templates. > > For non-template code the starting has before for backwards compatibility. The difference is you cannot > use ?> and text before the opening throws an error. > > > […] > > And those files can be included with something like require_template > or you can turn off the option in the ini file. > > The point is in EITHER MODE a php file that starts with work as it did before. The new mode would just disallow you to break > out of PHP code with ?>. > > > […] > > I'm not trying to kill anything. In fact what I'm proposing would be a > smooth transition to something that is already done. The difference is > at some point you won't be able to do this: > > class Object > { >    public function output() >    { > ?> > Print me! >    } > } > > I cringe every time I see this. There is no excuse since we have here/nowdocs. > > For people that use PHP as a template there can be other options. I'm > not totally against a new keyword, but I am against a new keyword for > including normal PHP code. It just doesn't make sense. No matter what > you name it (require_code, require_file, require_path) it's damned > confusing. If you did it the other way around its much clearer: > require_template. > > With require_template you're also free to expand template > functionality while keeping code clearly separated. > > > […] > > It's not as much as adding a keyword as it is what keyword you're adding. > > I hope the way I've explained things makes sense. > > Luke > > > […] -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com --- ## #59519 — Tom Boutell — 2012-04-09T17:23:05+00:00 URL: https://externals.io/message/59466#59519 · In reply to: #59518 Also, your objection - that 'require_code' is confusing - would most likely be an issue for a handful of people who write autoloaders. Those clean PHP class files are almost always autoloaded. > I see what you're saying, but you're proposing a new keyword to > include code that does what plain old 'require' does now (assuming > it's not a nice clean class file that is being included). Which means > that valid code today is busted code once this feature comes out. That > seems like a very hard sell. > > > > […] > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com --- ## #59522 — Luke Scott — 2012-04-09T17:36:38+00:00 URL: https://externals.io/message/59466#59522 · In reply to: #59519 > Also, your objection - that 'require_code' is confusing - would most > likely be an issue for a handful of people who write autoloaders. > Those clean PHP class files are almost always autoloaded. Not really. Has nothing to do with auto loaders. require_code - A literal string? Is this eval? require_path - A directory? require_file - What kind of file? You have to look at the keywords you're proposing and try to explain then without prior knowledge or documentation. These keywords are also ambiguous. require/include are well understood for including code not templates. Not just for PHP. require_template on the other hand is clear and to the point. It's hard to make the same kind of assumptions as you can with the other keywords. And with those who know PHP it's readily apparent require_template could mean short tags whereas the other leave you scratching your head. Luke > > > > […] > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com --- ## #59523 — Ralph Schindler — 2012-04-09T17:43:10+00:00 URL: https://externals.io/message/59466#59523 · In reply to: #59519 Hey Tom, An idea, why not overload require/include with a second parameter that simply enforces an include mode. For example // in some autoloader (include, requires, and *_onces) include $pathToFile, INCLUDE_MODE_PHP_ONLY; This would tell the parser/executor to start in PHP mode and never leave it, that way, ending tags would throw a runtime/execution error. Other constants and behaviors could be: INCLUDE_MODE_PHP_START; INCLUDE_MODE_PASSTRHOUGH_START; (the current and default behavior) This would have the least amount of impact on BC, and seeminlyg would be a friendly change to the lexer/syntax. Thoughts? -ralph > Also, your objection - that 'require_code' is confusing - would most > likely be an issue for a handful of people who write autoloaders. > Those clean PHP class files are almost always autoloaded. > > > > […] --- ## #59525 — Luke Scott — 2012-04-09T17:51:06+00:00 URL: https://externals.io/message/59466#59525 · In reply to: #59523 > Hey Tom, > > An idea, why not overload require/include with a second parameter that simply enforces an include mode. For example > > // in some autoloader (include, requires, and *_onces) > include $pathToFile, INCLUDE_MODE_PHP_ONLY; > > This would tell the parser/executor to start in PHP mode and never leave it, that way, ending tags would throw a runtime/execution error. > > Other constants and behaviors could be: > > INCLUDE_MODE_PHP_START; > INCLUDE_MODE_PASSTRHOUGH_START; (the current and default behavior) > > This would have the least amount of impact on BC, and seeminlyg would be a friendly change to the lexer/syntax. > > Thoughts? If this were to happen: - I would prefer much shorter elegant constants. - A constant for suppressing warnings thrown by include without suppressing warnings/errors by the actual file -- I think we can all agree @include is counter productive since it does much more that suppress warnings thrown by include (even parse errors!). Luke > > -ralph > > > > > > […] --- Next page: https://externals.io/message/59466.md?page=2