>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 >> > -- 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
