Hi, I modified the title.
> * include vs. require behavior (warning vs. error on failure) > * once vs. every time (require_once vs. require) > > And we are proposing a third: Then, better name would be require_script()/include_script(). However, this option will not solve script inclusion security issues. Fixing security issues will not have much opposition, but adding new syntax will. I like embedded languages, but programmers can write vulnerable code with it. Embed feature is better to be controlled by programmers/ administrators for better security. Regards, P.S. I'm uncomfortable with current PHP, since someone may write "include $_GET['module']" or like for my systems. This code raises fatal security issue with current PHP, but it's not with my proposal. -- Yasuo Ohgaki yohg...@ohgaki.net 2012/4/9 Tom Boutell <t...@punkave.com>: > Thanks. However, would you please fix the summary on the RFC's page to > match the summary in the actual RFC? As you have written it, it > implies that support for <?php would be completely removed. This is > not the case. > > As for adding a boolean parameter to the require keyword, as the RFC > mentions there are already at least two distinctions already when > requiring files in PHP: > > * include vs. require behavior (warning vs. error on failure) > * once vs. every time (require_once vs. require) > > And we are proposing a third: > > * start in php mode vs. start in html mode > > We already have four keywords for requiring files. At this point it > does not make sense to keep introducing more keywords (we would need 8 > with this change). Your boolean flag proposal keeps it to four > keywords, but as soon as someone adds another flag it will become > awkward to remember them. Since PHP does not have named parameters I > think an associative array is the best way to go (especially with the > new short syntax). > > Also I don't think it makes sense to forbid shifting into html mode > later in the file, it could reduce support for the proposal needlessly > - since it already lets people who want to write clean all-PHP files > do so, and some of those people might have legitimate reasons to use > HTML mode in the scope of a function or method (where it does not > suddenly introduce whitespace without being explicitly called, etc). > > But if it really came down to it I could live with an "absolutely > nothing but PHP" behavior when the code flag is true (supporting <?php > when the flag is not set is a must of course). > > On Sun, Apr 8, 2012 at 6:45 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: >> Hi, >> >> I talked on twitter. >> Yes, he is kidding, but he is serious, too. >> >> I've added the RFC to Under Discussion and added >> security issue description. I also added my proposal that >> controls embed mode. >> >> BTW, I don't think we need new "require_path" why don't >> we use >> >> require "file.php", ture; >> >> or some thing similar? >> I prefer to use switch, since security countermeasure is >> better to be enforced by switch. >> >> Regards, >> >> -- >> Yasuo Ohgaki >> yohg...@ohgaki.net >> >> >> >> 2012/4/9 Tom Boutell <t...@punkave.com>: >>> Moriyoshi was kidding, as near as I can tell (: >>> >>> To take it at face value though, the *cough* April 1st *cough* >>> proposal of Moriyoshi calls for the complete abolition of the feature >>> with no backwards compatibility with existing code that uses PHP as a >>> template language... including most popular frameworks that sensibly >>> obey a separation between class files and template files but still use >>> PHP rather than a dedicated templating language for templates. >>> >>> I don't think that's realistic (and neither did the author it >>> appears). Since PHP's usability as a template language may conceivably >>> be improved by other proposals, it is undesirable as well even if you >>> don't currently find PHP to be a suitable template language. >>> >>> Please read my proposal over carefully as it does address the obvious >>> issues that make Moriyoshi's proposal possibly less than serious in >>> intent (: >>> >>> I would oppose a php.ini flag for this as that gives us two >>> incompatible versions of the current version of the language to worry >>> about and makes the feature effectively unusable in reusable code. >>> This approach has created problems before. >>> >>> On Sun, Apr 8, 2012 at 5:55 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: >>>> Hi, >>>> >>>> There is RFC that is written by Moriyoshi. >>>> It's not listed in RFC page, though. >>>> >>>> https://wiki.php.net/rfc/nophptags >>>> >>>> I think these should be merged. >>>> >>>> Regards, >>>> >>>> -- >>>> Yasuo Ohgaki >>>> yohg...@ohgaki.net >>>> >>>> >>>> >>>> 2012/4/9 Yasuo Ohgaki <yohg...@ohgaki.net>: >>>>> Hi, >>>>> >>>>> Moriyoshi has created same entry on 4/1, but >>>>> it seems it was deleted already. >>>>> >>>>> Anyway, he had a patch for it. >>>>> >>>>> https://gist.github.com/2266652 >>>>> >>>>> As I mentioned in other thread, we should better to have >>>>> a switch to disable embed mode for security reasons. >>>>> >>>>> Regards, >>>>> >>>>> -- >>>>> Yasuo Ohgaki >>>>> yohg...@ohgaki.net >>>>> >>>>> >>>>> >>>>> 2012/4/9 Tom Boutell <t...@punkave.com>: >>>>>> 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
