Re: Re: Go for votes for the open tag-less PHP files

On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmer <vchkpw@developersdesk.com>wrote: > On 4/16/2012 3:31 AM, Arvids Godjuks wrote: > >> That's sad really, to be honest. >> I wonder if people even use this: >> >> echo include 'foo.bar', 'baz'; >>> >> > Probably not, Try it! you get: > > 1baz > > It actually works more like > > echo (include "foo.bar"), 'baz'; > > than > > > echo include( "foo.bar"), 'baz'; > > > > More important include doesn't currently allow multiple parms: > > include "foo.bar", 'baz'; > > Parse error: syntax error, unexpected ',' in bla.php on line xx > > > > > Rick > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I'll reiterate my position that I'm not ready to bring my RFC to a vote; and even if I was, the rules wouldn't allow it. In fact, unless I'm mistaken, none of the RFCs have met the 2-week minimum requirement yet, so no vote can take place at this time. But I do think we're making progress, so I would ask for a little extra patience from the peanut gallery for now. =) To Arvids' point, I'm definitely leaning in that direction, but I'd like to hear a little bit more from anyone who believes a different approach would be better. If nobody speaks-up, I'll just assume that we have consensus on that point and add it to the RFC. Regarding include/require, I agree that any BC break would be extremely minimal. In the 10+ years I've been developing PHP, I don't think I've ever once seen somebody include multiple scripts on a single line (I wasn't even aware that such a thing was allowed). So if it does pose a change, I'd be surprised if any existing scripts would be affected. And since this is a major version increment we're talking about here, I think a small amount of allowance can be made for low-impact BC breakage IMHO. How about we just keep the parentheses optional and comma-seperate the arguments? For example, the require syntax could look like this: require[(] $script_filename, $script_type = PHP_SCRIPT_TYPE_NORMAL [)]; Possible values for $script_type: PHP_SCRIPT_TYPE_NORMAL (0x01) - If the included file contains PHP code, parse it. PHP_SCRIPT_TYPE_TAGLESS (0x02) - Code is assumed to be PHP throughout the script. The <?php tag throws E_NOTICE and the ?> tag throws E_RECOVERABLE_ERROR. PHP_SCRIPT_TYPE_STACK (0x04) - The $script_type is applied to all child scripts of the one being included. - Question : Would anyone see value in adding an override constant that, while not recommended, allows the developer to apply a different $script_type somewhere deeper in the stack? Personally this doesn't sound useful to me, but I'd be willing to put it in if enough of you wanted it. PHP_SCRIPT_TYPE_CODE_FILE (PHP_SCRIPT_TYPE_NORMAL & PHP_SCRIPT_TYPE_TAGLESS) - The entire script is assumed to be PHP code and is parsed accordingly. PHP_SCRIPT_TYPE_CODE_STACK (PHP_SCRIPT_TYPE_NORMAL & PHP_SCRIPT_TYPE_TAGLESS & PHP_SCRIPT_TYPE_STACK) - The entire script and all its child scripts (i.e. its "stack") are assumed to be PHP code and parsed accordingly. What do you think? --Kris