Hi Tom 2012/4/7 Tom Boutell <t...@punkave.com>: > Now that the flamewar has died down a little I'd like to try to have a > civil discussion about this idea - *without* my admittedly > inflammatory suggestion to kill <?php altogether.
While I'm +0 on the idea of making <?php optional, here are some thoughts. > > So here is what I am seriously suggesting: > > * The default behavior doesn't change. The parser starts out in HTML mode. > > * If the CLI sees a .phpc file extension, the parser starts out in PHP > mode (no opening <?php is required). It is still possible to shift > into HTML mode after that with ?>. > > * If a require/include statement sees a .phpc file extension, the > parser starts out in PHP mode. CLI, or any other SAPI for the matter, doesn't care about the file extension, as pointed out by several posts. This makes it impossible to correctly determine the input file for a require/include statement. The only option that would make sense is a new parser mode, which could be specified by a CLI parameter, or by an INI option (absolutely least favorable option, if any even wanna call it that). A CLI argument is simple and elegant, but does require those 3 extra keystrokes or so: C:\> php -S bug42.php While it does create another issue, which is that the mode is not available to other SAPI's, and I think adding a specialized option for each SAPI for such things will be bad, but might be a better way to do at webserver level than php.ini level, but personally I don't like a dynamic language that have a dynamically changed syntax, which makes it seem inconsistent. Hope this was some constructive feedback if you decide to write an RFC about it. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
