Edit report at https://bugs.php.net/bug.php?id=61182&edit=1
ID: 61182 Comment by: phpmpan at mpan dot pl Reported by: tom at tomwardrop dot com Summary: Assume Opening PHP Tag Status: Open Type: Feature/Change Request Package: *Configuration Issues PHP Version: 5.4.0RC8 Block user comment: N Private report: N New Comment: So, basically, you're suggesting that programmers should write "<?php>" at the begining of the file to not write "<?php". Blarg. Of course this "<?php>" thing is optional. The problem is that virtually any code has to use it to be portable. This means it's not really optional. Previous Comments: ------------------------------------------------------------------------ [2012-02-25 09:24:21] tom at tomwardrop dot com Are there not other directives that can break a lot of code? Remember, this would default to off. I don't see why as a server owner, I should have this option made unavailable purely because it can break other code. If you wanted to write code that worked regardless of this setting, you could do something like: <?php init_set('implicit_open_tag', false) ?> Of course, for that to work then implicit_open_tag is On, the parser would have to ignore the "<?php". The rule could be that if <?php is the first non- whitespace sequence encountered in the file, then it's ignored. 'optional_open_tag' may therefore be a more appropriate name for this setting. Except for legacy templates which may start with something other than <?php, this would allow for cross-environment code. Any such template code that breaks, would break in a manner no different to how new features like namespaces break in older version of PHP. A new tag could be introduced: "<?php>". This would be shorthand for opening and closing a php tag, and should be placed at the top of any template file that has the requirement to work regardless of whether the opening tag is optional. I hope this idea isn't dismissed on the grounds that it's difficult to implement, because I think it's workable. Having optional opening tags would no doubt be a step in the right direction for PHP, and I'm sure that if you didn't have backwards compatible to be concerned about, you'd probably make opening tags implicit with no option to make it otherwise. As I said earlier, the decision to make the opening tag explicit was desirable at the time PHP was conceived, but I believe it's one of those legacy decisions that needs to be re- evaluated. ------------------------------------------------------------------------ [2012-02-25 08:50:31] ras...@php.net So this would basically be a "break all existing code" .ini switch? I don't think that is a good idea. ------------------------------------------------------------------------ [2012-02-25 08:37:03] tom at tomwardrop dot com Description: ------------ PHP is probably the only language I know which requires an opening tag (i.e <? php). It's one of those things with PHP that people rarely question. While PHP is a rather unique programming language in that it's basically a templating engine at its core, I feel that requiring the opening <?php is not catering to the majority of the use cases. Instead, I'd rather PHP assume that the file being executed has PHP from line 1 which is most commonly the case. In the less common scenario where PHP is not the first text encountered, the user would need to close the assumed PHP execution block with a ?>. In the early days, when web pages were mostly static, and PHP was used to add dynamic elements, it made sense to require an opening tag to drop-into PHP execution. These days however, the opposite is more often the case. You normally have a complete PHP web application, into which HTML and other static text is inject, rather than injecting dynamic elements into static web pages. What I'd like to see is a new directive added to php.ini. Call it what you want, e.g. assume_open_tag or omit_open_tag. This would require a few changes in coding practice. For example, if omit_open_tag is On, then the behaviour of the include() and require() constructs will change. They too will assume the files being required contain PHP from line 1. Programmer will not longer be able to use include() and require() to load file contents, instead the programmer would have to use file_get_contents or some other alternative, though this would arguably a good thing, as using require() and include() to load and output non-php could be vulnerability, hence it's already bad practice to use include/require() to load non-PHP files. I think this change would be consistant with some of the changes made in 5.4 which demonstrates PHP embracing modern programming idioms from other languages. Ideally, I'd like this to become the default behaviour of PHP, though obviously for at least the first major release, it would of course be defaulted to Off. Thoughts? ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=61182&edit=1