On Mon, Apr 9, 2012 at 3:34 PM, Luke Scott <l...@cywh.com> wrote: > Tom, > > On 4/9/12 3:17 PM, "Tom Boutell" <t...@punkave.com> wrote: > > >My original goal was to stop typing <?php in pure code files. That > >includes at the top. I think it's entirely reasonable to achieve it > >with an option to the require keywords for this purpose and a naming > >convention to be followed by autoloaders. Keep in mind how rarely you > >have to change them. We're talking about code maintained by a > >relatively small number of very sharp developers. They can handle a > >few flags (: >
Again though, the problem here is that you're relying on the *including*script to determine whether a PHP script is pure or not; i.e. this approach leaves no way for that to be determined in the file itself. For example, I can see perfectly valid instances where it would be ideal to execute one of these pure scripts as a direct call to the webserver-- AJAX being a prime example. I.e. cases where you want backend PHP processing to take place but it has to be accessed via the browser (most likely "hidden" as an AJAX query though). So without the ability to do that, I just don't think this passes the usefulness test for me. And if we do have the ability to specify that in the file, on the other hand, then that would pretty much eliminate the need for a require flag anyway. The only alternative I can see would be to allow something to be passed in the headers telling the webserver to parse a script as PHP instead of HTML. But I don't know if that would be extremely simple or extremely problematic. --Kris > > > >The prohibition of ?> still seems unnecessary and perhaps divisive, > >but if it were preferable to the majority to prohibit ?> in a pure > >code file, I could live with that as long as classic PHP files are > >also 100% supported and remain the default. I'm trying to craft a > >broadly acceptable compromise that still achieves the original goal of > >allowing people to write "just code" in a class file. > > > I think you can you achieve that by making "template mode" default and the > default changeable in the php.ini file. > > Something like this: > > /* > Code only, <?php at top optional, no ?>. > Text before opening <?php silently dropped > > */ > > require "/path/to/somefile.php", INCLUDE_CODE; > > /* > Works exactly as it is now: <?php and ?> allowed. > Text betweeen ?>...<?php printed to output buffer. > */ > > > > require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now > > /* > By default INCLUDE_TEMPLATE > Can change default mode in php.ini to be INCLUDE_CODE if desired. > */ > > require "/path/to/anotherfile.php"; // As it is now > > > Personally I would like to be able to do something like this in my auto > loader: > > include $file, INCLUDE_CODE & INCLUDE_SILENT; > > > > That way I can ensure pure code is being inserted and no warnings are > thrown if the file doesn't exist (class undefined will be thrown anyway). > > I think it's important to make <?php optional at the top if you're using > existing or third party libraries that you can't modify. At least then > you'll be able to maintain backwards compatibility with most code written > since PHP 5. > > (We don't need PHP_*. See the output of get_defined_constants() ). > > I like where this is going! Hopefully after the RFC has been finalized > everyone else will agree. > > > > > >On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig <kris.cr...@gmail.com> wrote: > > > Kris, > > > > >> > >> > >> Bah, right! That damned <?xml tag.... > >> > >> I already know what everyone's reaction will be, and it is probably a > >>REALLY > >> bad idea, but I feel obligated to at least mention it: Should we > >>consider > >> replacing "<?..." with something that doesn't conflict with anything, > >> perhaps starting in PHP 6? No need to get out the torches and > >>pitchforks, > >> everyone! As insane and problematic as that would be (i.e. BC break > >>with > >> roughly 1/3 of the internet lol), I felt as though the subject should at > >> least be broached. ;P > > > No need. Just keep it as <?php. It's already been well established. We > should ovoid overcomplicating it. > > Luke > > >
