RFC: source files without opening tag View as Markdown

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 <?php would be completely removed. This is
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 <?php
when the flag is not set is a must of course).

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@punkave.com:

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.

On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki yohgaki@ohgaki.net
wrote:

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 yohgaki@ohgaki.net:

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 tom@punkave.com:

I have written an RFC proposing backwards-compatible support for
source files without an opening <?php tag:

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

--

--
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

--

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 <?php tag and the ?> 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 <?php tag of the included file would be
ignored. Everybody's happy. No BC breaks. No additional flags/keywords
to muddle around with.

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

Hi,

I modified the title.

• 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 tom@punkave.com:

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 <?php would be completely removed. This is
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 <?php
when the flag is not set is a must of course).

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@punkave.com:

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 yohgaki@ohgaki.net:

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 tom@punkave.com:

I have written an RFC proposing backwards-compatible support for
source files without an opening <?php tag:

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

--

--
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

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

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.

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. <?php should be optional at the start of
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 <?php
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 <?php tag is
impractical. It makes much more sense to have a keyword for templates.

For non-template code the starting <?php tag should always work as it
has before for backwards compatibility. The difference is you cannot
use ?> and text before the opening <?php tag is either ignored or
throws an error.

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 <?php. I
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 <?php will
work as it did before. The new mode would just disallow you to break
out of PHP code 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:

<?php
class Object
{
public function output()
{
?>
Print me!
<?php
}
}

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.

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,

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 <?php ? Because it's become somewhat
confusing to keep track of what is being talked about. If that is the
case, continue reading.

I would prefer the starting <?php tag be optional rather than removed.
Just explicitly forbid the ending ?> tag and treat text before the
opening <?php tag differently. Perhaps ignore it (rather than print)
or throw an error.

That is at least how I would prefer the "code" mode as most
non-template files only start with <?php. It allows for backwards
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

I have written an RFC proposing backwards-compatible support for
source files without an opening <?php tag:

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

--

--
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

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

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.

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.

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.<?php should be optional at the start of
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<?php
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<?php tag is
impractical. It makes much more sense to have a keyword for templates.

For non-template code the starting<?php tag should always work as it
has before for backwards compatibility. The difference is you cannot
use ?> and text before the opening<?php tag is either ignored or
throws an error.

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<?php. I
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<?php will
work as it did before. The new mode would just disallow you to break
out of PHP code 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:

<?php
class Object
{
public function output()
{
?>
Print me!
<?php
}
}

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.

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,

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<?php ? Because it's become somewhat
confusing to keep track of what is being talked about. If that is the
case, continue reading.

I would prefer the starting<?php tag be optional rather than removed.
Just explicitly forbid the ending ?> tag and treat text before the
opening<?php tag differently. Perhaps ignore it (rather than print)
or throw an error.

That is at least how I would prefer the "code" mode as most
non-template files only start with<?php. It allows for backwards
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

I have written an RFC proposing backwards-compatible support for
source files without an opening<?php tag:

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

--

--
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