For some this is sufficient, for others (like myself) getting rid of the initial <?php for pure files is a primary motivation.
On Mon, Apr 16, 2012 at 9:38 AM, Arvids Godjuks <arvids.godj...@gmail.com> wrote: > 16 апреля 2012 г. 11:05 пользователь Kris Craig <kris.cr...@gmail.com>написал: > >> Arvids, >> >> >> On Mon, Apr 16, 2012 at 12:46 AM, Arvids Godjuks <arvids.godj...@gmail.com >> > 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 <?php tags and using special >>> 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 >> >> 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 <?php tags in source files - just make sure they > 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 <?php ?> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
