.phpp would be fine. .phpp code needs to be able to interoperate with .php templates, otherwise one can't supply reusable libraries that implement generic algorithms without surprises for those who integrate them in older projects.
Sent from my iPhone On Apr 9, 2012, at 1:16 AM, Kris Craig <kris.cr...@gmail.com> wrote: > Tom, > > On Sun, Apr 8, 2012 at 4:14 PM, Tom Boutell <t...@punkave.com> wrote: > 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 > > > I think this is a great idea overall, but it seems to me as though we're > needlessly over-complicating things. If we just go with a separate file > extension for pure PHP code (i.e. everything in the file is parsed as if it > was contained in a <?php tag and the ?> tag would throw an error), then > there's no need for adding new keywords or INI flags. If a pure PHP file > includes a regular PHP file that contains HTML, a warning would be thrown and > anything not within the <?php tag of the included file would be ignored. > Everybody's happy. No BC breaks. No additional flags/keywords to muddle > around with. > > That said, we might want to consider a file extension other than ".phpc". > There are some PHP-related projects/commits that already use this file > extension for other purposes and could be broken by this. Probably wouldn't > be a huge deal but a quick Google search shows that we would be stepping on a > few people's toes by going with that extension. > > Instead, how about going with ".phpp" (as-in, "PHP Pure")? A Google search > on that shows it's not being used anywhere (except for one blog post from > 2007 that linked to a .phpp file, but it looks like he just named it that so > that it wouldn't be parsed by the webserver). That way we wouldn't be > creating any conflicts with existing applications/projects. =) > > --Kris >
