you are not making valid points you are proposing DANGEROUS changes! what happens if PHP 5.4.x will follow your wishes (what never will happen) and your file without <?php will be called on a machine with a lower php-version?
what you also do not realize is that the world is not turning around your windows machine - in the unix world extensions are meaningless - the sheabing and execute permissions are the only things controlling if a zexzfile is executeable and with which interpreter this happens and no the world is not turning around you or even around PHP this is how unix-systems and shells are working and there is no place for funny execptions in this world Am 07.04.2012 15:39, schrieb Tom Boutell: > From the viewpoint of someone writing reusable classes, the need to > start with <?php and reprimand anybody who accidentally puts a newline > above it is a silly annoyance they don't experience with other tools. > > That said, you are making valid points, I'm not convinced myself that > "file extensions" necessarily should or could be determined in every > context. But it seems the most viable way of addressing the issue - if > a viable way even exists. Partly I want to convince myself that this > either can or can't ever be improved, and move on either way (: > > On Sat, Apr 7, 2012 at 9:35 AM, Crocodile <crocodil...@gmail.com> wrote: >> Hello, Tom... >> >> Are you seriously that bothered with '<?php' at the top of your classes? Are >> you serious when talking changing reguire/include behaviour just to satisfy >> your wish? >> >> To be also serious, I would mention the possibility of including URLs. There >> is no such thing as file name extension in URLs. Thus your idea should be >> forgot. Personally, I really think 1st of April is like continuing in the >> internals mailing list... >> >> 2012/4/7 Tom Boutell <t...@punkave.com> >>> >>> Now that the flamewar has died down a little I'd like to try to have a >>> civil discussion about this idea - *without* my admittedly >>> inflammatory suggestion to kill <?php altogether. >>> >>> So here is what I am seriously suggesting: >>> >>> * The default behavior doesn't change. The parser starts out in HTML mode. >>> >>> * If the CLI sees a .phpc file extension, the parser starts out in PHP >>> mode (no opening <?php is required). It is still possible to shift >>> into HTML mode after that with ?>. >>> >>> * If a require/include statement sees a .phpc file extension, the >>> parser starts out in PHP mode. >>> >>> * If mod_php and FPM are able to see the path (I'm honestly not sure >>> if they can or not), they look for .phpc as their indication to start >>> out in PHP mode. If that's not possible then new options are defined >>> to allow Apache to be configured to tell mod_php and/or FPM to do the >>> right thing based on mime types etc. >>> >>> This way .php continues to behave exactly as it does today, and can >>> interoperate smoothly with code that uses .phpc. .phpc can require >>> .php and vice versa. They are friends. >>> >>> Thoughts? >>> >>> -- >>> 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 >>> >> > > > -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm
signature.asc
Description: OpenPGP digital signature
