On 15/04/12 16:29, Kris Craig wrote: > On Sat, Apr 14, 2012 at 11:20 PM, John LeSueur <john.lesu...@gmail.com>wrote: > > > The second thing that still needs nailing down as far as implementation is > how to determine parsing mode. If it has to be specified at include time, > then we're putting the burden on whoever writes the autoloader to know what > kind of file it is. If it has to be specified in php.ini, or in the sapi > configuration, then I'm putting the burden on the administrator. I want to > allow the developer who writes the file to specify its parsing mode. > > The two ways I see for developers to do so is to use variations on the > <?php header of the file, or by file extension. I prefer variations on the > <?php header, because file extension still depends on configuration in > order to work, so involves admins in the decision of how to parse the php > files that I write. > > <?php means just what it does now. > <?phpp means, disallow ?>, and error if there is anything before the > header. The RFC specifies an additional restriction, throw error if I > include file with <?php header. > <?phpo (open to suggestions for the text of this header) means disallow > ?>, and error if there is anything before the header. > > Hmm as in "PHP Open?" That could work. > > This goes back to the question of whether to do a tag, an INI setting, or a > keyword. I'd already discounted an INI setting before I started the RFC, > but I'm still on the fence regarding the other two. I was hoping the > discussion could first focus on that question, since there's a lot of > complexity involved and it'll take some rigorous back-and-forth for us to > weigh all the pros and cons of each. But I do feel like we're starting to > get back on track at least. =) > > --Kris > >
The point of contention on my part has been on the restriction of the types of files that can be included from .phpp files. Even with the compromise per-file basis, I wouldn't approve, as it makes an unnecessary restrictions that require workarounds for .phpp files to play nice. For example, you wouldn't be able to write a universal autoloader in .phpp, as it would not be unable to include .php files. But then you wouldn't be able to include the autoloader in a .phpp file if the loader is defined in a .php file. Yes, there are workarounds, but it's this kind of WTF factor that will just end up annoying anyone trying to use .phpp files in their application. INI settings that dictate parsing rules are a non-starter in my opinion, so that just leaves the keyword solution, which I think is the direction the discussions of both Yasuo and Tom's RFCs were heading. >From a technical standpoint, I can see that as being acceptable (using keywords and removing include restrictions), but from a practical standpoint, I'm still not seeing the benefits. The problems that the RFC is supposed to solve (except the include restrictions) can already be solved in userland. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
