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
On 4/9/12 12:23 PM, Tom Boutell wrote:
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.
On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell<t...@punkave.com> wrote:
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.
On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott<l...@cywh.com> wrote:
On Apr 9, 2012, at 9:16 AM, Tom Boutell<t...@punkave.com> wrote:
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
On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott<l...@cywh.com> wrote:
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
On Apr 8, 2012, at 9:32 AM, Tom Boutell<t...@punkave.com> wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
