# Go for votes for the open tag-less PHP files - Thread: https://externals.io/message/59956 - Original archive: https://news-web.php.net/php.internals/59956 - Started by Pierre Joye on 2012-04-15T10:47:04+00:00 - Messages: 33 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/59956.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #59956 — Pierre Joye — 2012-04-15T10:47:04+00:00 URL: https://externals.io/message/59956#59956 hi! Without willing to end discussions prematurely, it looks to me that everything possible have been said about the various opening tags proposals. For one, I do not follow any of these discussions anymore. And I suppose I am not the only one. I would strongly suggest to move to the actual proposal phase and go for the voting phase. To do that, please try to merge the the three RFCs if possible to ease the voting process. ps: this is not a new thread to discuss this topic, so simply do whatever is necessary to move to the next phase, thanks :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #59958 — Kris Craig — 2012-04-15T11:00:36+00:00 URL: https://externals.io/message/59956#59958 · In reply to: #59956 > hi! > > Without willing to end discussions prematurely, it looks to me that > everything possible have been said about the various opening tags > proposals. Actually, we finally appear to be making some headway. I appreciate your concerns, but my RFC certainly is nowhere near ready to be voted on, and last time I checked the other two weren't, either. I don't want to spam the inboxes of people who aren't interested, but we do need to discuss this further before anything can move forward. I'm open to ideas on how we can accomplish both. Perhaps a new list for RFC-specific discussions? =) --Kris > For one, I do not follow any of these discussions anymore. > And I suppose I am not the only one. > > I would strongly suggest to move to the actual proposal phase and go > for the voting phase. To do that, please try to merge the the three > RFCs if possible to ease the voting process. > > > ps: this is not a new thread to discuss this topic, so simply do > whatever is necessary to move to the next phase, thanks :) > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #59960 — Pierre Joye — 2012-04-15T11:05:06+00:00 URL: https://externals.io/message/59956#59960 · In reply to: #59958 hi, >  Perhaps a new list for RFC-specific discussions?  =) We don't need yet a new list. Sit down together and get over your differences and create the RFC or more if you can't get over your differences. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #59965 — Tom Boutell — 2012-04-15T14:35:12+00:00 URL: https://externals.io/message/59956#59965 · In reply to: #59960 I don't think a consensus on the following points is likely to emerge without voting on them individually. I propose carrying out a vote with up to three questions to be answered depending on your response to each. We could then proceed to discuss the (relatively boring but essential) details of keywords and extensions, if any, and create a final RFC. Hopefully all parties can agree to be bound by the results of a vote on these three questions and work together to create a final RFC that abides by the result or let the matter drop. Let's briefly discuss whether these questions truly represent the major differences between the three RFCs (not the merits of those positions please) and then, I hope, carry out a vote on them so we can move on. The Questions: 1. Whether a "pure code" mode in which tags are not permitted at all in such a file: * Has merit and should be pursued (option 1a), or * Should be dropped entirely (option 1b). If your vote is for option 1a, please respond to the following additional question: 2. Whether "pure code" mode should be: * Toggled globally by a php.ini option such that tags are completely forbidden when this mode is active (option 2a), or * Switched on by keywords and SAPI options that allow the sysadmin and developer to make the choice at runtime, with the ability to make that choice differently for different files or invocations, so that a mix of "pure code" files and files that forbid can exist (option 2b). 3. If your vote is for option 2b, please respond to the following additional question: Whether "pure code" mode should: * Forbid requiring a non-pure file from a pure file (option 3a), or * Permit requiring non-pure files from pure files (option 3b). I believe Kris Craig and Yasuo Ohgaki will find that these questions accurately sum up our really significant unreconciled differences (and, with the inclusion of question 1, the position of those who don't want the feature at all). These three questions deliberately don't address what the keywords or file extensions or other mechanisms are called exactly, because I believe those issues to be fairly simple to agree upon once we have decided the basics. > hi, > > > > > […] > > We don't need yet a new list. Sit down together and get over your > differences and create the RFC or more if you can't get over your > differences. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > > > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com --- ## #59974 — Kris Craig — 2012-04-15T23:42:28+00:00 URL: https://externals.io/message/59956#59974 · In reply to: #59965 > I don't think a consensus on the following points is likely to emerge > without voting on them individually. I propose carrying out a vote > with up to three questions to be answered depending on your response > to each. We could then proceed to discuss the (relatively boring but > essential) details of keywords and extensions, if any, and create a > final RFC. > > Hopefully all parties can agree to be bound by the results of a vote > on these three questions and work together to create a final RFC that > abides by the result or let the matter drop. > > Let's briefly discuss whether these questions truly represent the > major differences between the three RFCs (not the merits of those > positions please) and then, I hope, carry out a vote on them so we can > move on. > > The Questions: > > 1. Whether a "pure code" mode in which top of a file, and the tags are not permitted at all in > such a file: > > * Has merit and should be pursued (option 1a), or > * Should be dropped entirely (option 1b). > > If your vote is for option 1a, please respond to the following > additional question: > > 2. Whether "pure code" mode should be: > > * Toggled globally by a php.ini option such that tags are > completely forbidden when this mode is active (option 2a), or > * Switched on by keywords and SAPI options that allow the sysadmin and > developer to make the choice at runtime, with the ability to make that > choice differently for different files or invocations, so that a mix > of "pure code" files and files that forbid can exist > (option 2b). > > 3. If your vote is for option 2b, please respond to the following > additional question: > > Whether "pure code" mode should: > > * Forbid requiring a non-pure file from a pure file (option 3a), or > * Permit requiring non-pure files from pure files (option 3b). > Question 3 may not be necessary given a possible new parallel approach being discussed. Please refer to my RFCs thread for details and to weigh in on that. > > I believe Kris Craig and Yasuo Ohgaki will find that these questions > accurately sum up our really significant unreconciled differences > (and, with the inclusion of question 1, the position of those who > don't want the feature at all). > > These three questions deliberately don't address what the keywords or > file extensions or other mechanisms are called exactly, because I > believe those issues to be fairly simple to agree upon once we have > decided the basics. > Overall, I like the idea, but I think it's premature. For my part, I still need more time to brainstorm and discuss. Keep in mind that my RFC was only drafted a few days ago and the RFC process requires a *minimum* of 2 weeks before a vote can be held. I'd prefer to adhere to that rule for the time being. I see no benefit in rushing things. I ask that everybody come back to the table and spend some more time trying to establish where we share common ground. I can't support a vote, at least on my RFC, at this time. > > > > […] > wrote: > > […] > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com --- ## #59975 — Kris Craig — 2012-04-15T23:43:19+00:00 URL: https://externals.io/message/59956#59975 · In reply to: #59974 err it might be 1 week, not 2. Either way, it's definitely too soon for mine to be voted on. --Kris > > > > > > […] > > Question 3 may not be necessary given a possible new parallel approach > being discussed. Please refer to my RFCs thread for details and to weigh > in on that. > > > > […] > > Overall, I like the idea, but I think it's premature. For my part, I > still need more time to brainstorm and discuss. Keep in mind that my RFC > was only drafted a few days ago and the RFC process requires a *minimum* of > 2 weeks before a vote can be held. I'd prefer to adhere to that rule for > the time being. I see no benefit in rushing things. I ask that everybody > come back to the table and spend some more time trying to establish where > we share common ground. I can't support a vote, at least on my RFC, at > this time. > > > > > […] --- ## #59976 — Kris Craig — 2012-04-15T23:44:38+00:00 URL: https://externals.io/message/59956#59976 · In reply to: #59975 Bah sorry everyone, I just woke up and I'm still a little groggy lol. It is in fact 2 weeks. --Kris > err it might be 1 week, not 2. Either way, it's definitely too soon for > mine to be voted on. > > --Kris > > > > > > […] --- ## #59982 — Yasuo Ohgaki — 2012-04-16T01:39:39+00:00 URL: https://externals.io/message/59956#59982 · In reply to: #59956 Hi, It would be better to vote - PHP will have script only (tag less) code or not then - How it will be implemented Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #59983 — Kris Craig — 2012-04-16T02:00:48+00:00 URL: https://externals.io/message/59956#59983 · In reply to: #59982 > Hi, > > It would be better to vote > > - PHP will have script only (tag less) code or not > > then > > - How it will be implemented > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > Awhile back, I raised the possibility of creating an RFC to expand the RFC voting process to allow for multiple questions, as well as provide clarity for cleaning-up "abandoned" RFCs, etc. This seems like exactly the kind of use case I had in mind. If I took some time this week to write a rough draft of a new RFC on this, is that something any of you would be interested in? --Kris --- ## #59986 — Arvids Godjuks — 2012-04-16T07:46:27+00:00 URL: https://externals.io/message/59956#59986 · In reply to: #59983 What happened with the proposal/RFC for expanding include/require with additional optional second param to allow for developers to define in place if he want's a pure PHP file to be included or a template file with direct HTML output? I like that proposal and take it over any other, because it gives developer a choice. And if things do not go the right way and he ends up screwing up somewhere - he is able to fall back to the old mode just by modifying the include/require statement (and in a MVC framework with autoload usage that would be 1-2 places in the whole project). All that stuff with keywords, removing Hi, > > It would be better to vote > > - PHP will have script only (tag less) code or not > > then > > - How it will be implemented > > Regards, > > That idea was raised a few times in the past, but Stas and others expressed, they (and maybe most people) can only vote for something, if the implementation details are tailored out (a patch is nice to have, but not necessary), otherwise you can't measure whether that change is feasible at all. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #59988 — Kris Craig — 2012-04-16T08:05:09+00:00 URL: https://externals.io/message/59956#59988 · In reply to: #59986 Arvids, On Mon, Apr 16, 2012 at 12:46 AM, Arvids Godjuks wrote: > What happened with the proposal/RFC for expanding include/require with > additional optional second param to allow for developers to define in place > if he want's a pure PHP file to be included or a template file with direct > HTML output? > I like that proposal and take it over any other, because it gives > developer a choice. And if things do not go the right way and he ends up > screwing up somewhere - he is able to fall back to the old mode just by > modifying the include/require statement (and in a MVC framework with > autoload usage that would be 1-2 places in the whole project). > All that stuff with keywords, removing extensions require a continuous effort from the developers, additional > support from the IDE/editors/other tools. Do we really need all that just > to give people the ability to load their scripts as a pure PHP code? > To my mind a modification to the include/require statements is all there > is required to add that extra thing that Kris want's so badly and does not > require to change your habbits, IDE templates, waiting for IDE/editors/WEB > source code highlight libraries/source analyzers/etc to catch up with the > change. > There is also a question I just raised that is not yet answered that the > keyword/extension thing can just break the valid performance tweak > technique, that is used extensively in any project with big code base. > That may very well be the method proposed in my RFC, too. I haven't made up my mind on that point as I'd like to cover the pros/cons a little more in depth (including the potential perf issue you just raised). A handler approach or something similar will still be necessary as well, since one key reason for my RFC was to make it so that these scripts could be executed directly via the webserver. But as for determining how PHP itself can identify a .phpp file, I think the three best options are: Create new tags, create new keywords, or create new parameters to existing keywords. I keep bouncing back and forth on which one I think is best, which tells me that I need to hear more debate on that. Thoughts? --Kris --- ## #59991 — Ferenc Kovacs — 2012-04-16T08:24:02+00:00 URL: https://externals.io/message/59956#59991 · In reply to: #59986 On Mon, Apr 16, 2012 at 9:46 AM, Arvids Godjuks wrote: > What happened with the proposal/RFC for expanding include/require with > additional optional second param to allow for developers to define in place > if he want's a pure PHP file to be included or a template file with direct > HTML output? > I like that proposal and take it over any other, because it gives developer > a choice. there is a valid issue which was discussed on irc yesterday: because include/require is a language construct, not a method, one is allowed, even advised to write the include/require calls without putting out the parentheses. if we introduce additional arguments for include/require, the following code will break: echo include 'foo.bar', 'baz'; as currently it was interpreted as echo include('foo.bar'), 'baz'; ofc. we could make that the additional params to include, require would only used, if the parentheses are uses, but that would make require/include inconsistent with every other language construct, where the parentheses is optional. so we either accept this BC, or not pursue this option, but go with the new functions/opcodes like include_code/require_code or similar. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #59994 — Arvids Godjuks — 2012-04-16T09:31:14+00:00 URL: https://externals.io/message/59956#59994 · In reply to: #59991 16 апреля 2012 г. 11:24 пользователь Ferenc Kovacs написал: > > > On Mon, Apr 16, 2012 at 9:46 AM, Arvids Godjuks wrote: > > > […] > > > there is a valid issue which was discussed on irc yesterday: > because include/require is a language construct, not a method, one is > allowed, even advised to write the include/require calls without putting > out the parentheses. > if we introduce additional arguments for include/require, the following > code will break: > echo include 'foo.bar', 'baz'; > as currently it was interpreted as > echo include('foo.bar'), 'baz'; > ofc. we could make that the additional params to include, require would > only used, if the parentheses are uses, but that would make require/include > inconsistent with every other language construct, where the parentheses is > optional. > so we either accept this BC, or not pursue this option, but go with the > new functions/opcodes like include_code/require_code or similar. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > That's sad really, to be honest. I wonder if people even use this: > echo include 'foo.bar', 'baz'; > as currently it was interpreted as > echo include('foo.bar'), 'baz'; I even didn't know it worked that way and if I saw code like this before today I would consider it an error (I would discover that it actually works, but I definitively would rewrite that part in two lines as distinct operators them with ; instead of , between them) Maybe it's not that big deal and a BC break would not impact things a lot. What do you think? --- ## #59995 — Pierre Joye — 2012-04-16T10:00:41+00:00 URL: https://externals.io/message/59956#59995 · In reply to: #59965 hi Tom, > I don't think a consensus on the following points is likely to emerge > without voting on them individually. I propose carrying out a vote > with up to three questions to be answered depending on your response > to each. We could then proceed to discuss the (relatively boring but > essential) details of keywords and extensions, if any, and create a > final RFC. > > Hopefully all parties can agree to be bound by the results of a vote > on these three questions and work together to create a final RFC that > abides by the result or let the matter drop. > > Let's briefly discuss whether these questions truly represent the > major differences between the three RFCs (not the merits of those > positions please) and then, I hope, carry out a vote on them so we can > move on. Agreed on your proposed next steps. It would rock if you could lead this effort and come up with a RFC covering the various points. I would suggest to sit down together with the other RFCs' authors and get that done. But please, no more discussions here about that. Makes no sense :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #59997 — Tom Boutell — 2012-04-16T13:04:02+00:00 URL: https://externals.io/message/59956#59997 · In reply to: #59985 We could vote on whether we like the idea in principle, with the condition that the final proposal pass separately as a fully detailed rfc. That way you are telling the authors of these rfcs whether to keep trying and in what direction, but you are not forced to accept the end product. I would welcome such a vote just to end fruitless debate on the three points I mentioned. Sent from my iPhone > > > > […] > That idea was raised a few times in the past, but Stas and others > expressed, they (and maybe most people) can only vote for something, if the > implementation details are tailored out (a patch is nice to have, but > not necessary), otherwise you can't measure whether that change is feasible > at all. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu --- ## #60003 — Arvids Godjuks — 2012-04-16T13:38:10+00:00 URL: https://externals.io/message/59956#60003 · In reply to: #59988 16 апреля 2012 г. 11:05 пользователь Kris Craig написал: > Arvids, > > > On Mon, Apr 16, 2012 at 12:46 AM, Arvids Godjuks > […] > > > […] > > That may very well be the method proposed in my RFC, too. I haven't made > up my mind on that point as I'd like to cover the pros/cons a little more > in depth (including the potential perf issue you just raised). A handler > approach or something similar will still be necessary as well, since one > key reason for my RFC was to make it so that these scripts could be > executed directly via the webserver. But as for determining how PHP itself > can identify a .phpp file, I think the three best options are: Create new > tags, create new keywords, or create new parameters to existing keywords. > I keep bouncing back and forth on which one I think is best, which tells > me that I need to hear more debate on that. Thoughts? > > --Kris > > I would encourage you to take a deep look into modifying the include/require statements, because for all the issues popped out with .pphp and keywords they just don't exist with include/require. And there is no need to remove the at the end and hey (for my case - my IDE removes all leading and trailing spaces on file save), your include 'file', PHP_SOURCE_ONLY; works fine, but including a template fails (as does an image with embedded tags uploaded through a security hole) . It's clean (although some BC break would occur, but I think it's minor), simple and 100% voluntary. Any decently written 3rd party library will work without any modification (well, removing trailing ?> is a matter of simple script if required, but I haven't seen people putting ?> in the end for years). --- ## #60004 — Tom Boutell — 2012-04-16T14:45:13+00:00 URL: https://externals.io/message/59956#60004 · In reply to: #60003 For some this is sufficient, for others (like myself) getting rid of the initial wrote: > 16 апреля 2012 г. 11:05 пользователь Kris Craig написал: > > > […] > include/require statements, because for all the issues popped out with > .pphp and keywords they just don't exist with include/require. And there is > no need to remove the start first thing in the file and there is no ?> at the end and hey (for my > case - my IDE removes all leading and trailing spaces on file save), your > include 'file', PHP_SOURCE_ONLY; works fine, but including a template > fails  (as does an image with embedded tags uploaded through a > security hole) . > It's clean (although some BC break would occur, but I think it's minor), > simple and 100% voluntary. Any decently written 3rd party library will work > without any modification (well, removing trailing ?> is a matter of simple > script if required, but I haven't seen people putting ?> in the end for > years). -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com --- ## #60006 — Rick WIdmer — 2012-04-16T17:31:41+00:00 URL: https://externals.io/message/59956#60006 · In reply to: #59994 > That's sad really, to be honest. > I wonder if people even use this: > > > […] 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 --- ## #60008 — Kris Craig — 2012-04-16T19:02:58+00:00 URL: https://externals.io/message/59956#60008 · In reply to: #60006 On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmer wrote: > > > > […] > 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 > > > > -- > > > > 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 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 --- ## #60010 — Rick WIdmer — 2012-04-16T19:39:40+00:00 URL: https://externals.io/message/59956#60010 · In reply to: #60008 > On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmerwrote: > > […] > 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). See above. It is not allowed now. > 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 [)]; include/require are language constructs. They do not require () around the parms, and making it optional probably isn't reasonable. OTOH, since it currently only allows one parm, adding a second, optional parm should be no problem. --- ## #60011 — Nikita Popov — 2012-04-16T19:51:34+00:00 URL: https://externals.io/message/59956#60011 · In reply to: #60010 > > > […] > See above.  It is not allowed now. I think there is a misunderstanding here. Inclusions with two arguments are currently not allowed, yes. The point is that adding such a second argument would make the grammar ambiguous. E.g, consider this: func(include 'foo', $someThing); Currently this is interpreted as the return value of 'foo' and the variable $someThing being passed to func. If you add a second argument it's unclear what this does. Is this a two-argument include? I.e. should it be interpreted as func((include 'foo', $someThing)); Or is this a one-argument include and should be interpreted as func((include 'foo'), $someThing); In my eyes such an ambiguity renders any proposal to add another argument to include completely unacceptable. The only option is to add a dedicated syntax for it like include 'foo' as $flags; Nikita --- ## #60012 — Kris Craig — 2012-04-16T19:54:06+00:00 URL: https://externals.io/message/59956#60012 · In reply to: #60011 On Mon, Apr 16, 2012 at 12:51 PM, Nikita Popov wrote: > On Mon, Apr 16, 2012 at 9:39 PM, Rick WIdmer > wrote: > > […] > > I think there is a misunderstanding here. Inclusions with two > arguments are currently not allowed, yes. The point is that adding > such a second argument would make the grammar ambiguous. > > E.g, consider this: > > func(include 'foo', $someThing); > > Currently this is interpreted as the return value of 'foo' and the > variable $someThing being passed to func. > > If you add a second argument it's unclear what this does. Is this a > two-argument include? I.e. should it be interpreted as > > func((include 'foo', $someThing)); > > Or is this a one-argument include and should be interpreted as > > func((include 'foo'), $someThing); > > In my eyes such an ambiguity renders any proposal to add another > argument to include completely unacceptable. > > The only option is to add a dedicated syntax for it like > > include 'foo' as $flags; > > Nikita > > -- > > > > Hmm I like that idea. Anyone see any downsides to using "as" instead of comma delination? --Kris --- ## #60019 — Tom Boutell — 2012-04-16T21:25:32+00:00 URL: https://externals.io/message/59956#60019 · In reply to: #60012 I think the 'as' solution is smart. > On Mon, Apr 16, 2012 at 12:51 PM, Nikita Popov wrote: > > > […] > Hmm I like that idea.  Anyone see any downsides to using "as" instead of > comma delination? > > --Kris -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com --- ## #60020 — Tom Boutell — 2012-04-16T21:30:43+00:00 URL: https://externals.io/message/59956#60020 · In reply to: #60019 This has been added in version 1.1.1 of the source_files_without_opening_tag RFC: https://wiki.php.net/rfc/source_files_without_opening_tag > I think the 'as' solution is smart. > > > > […] > > > > -- > 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 --- Next page: https://externals.io/message/59956.md?page=2