On 4/9/12 5:02 PM, "Kris Craig" <kris.cr...@gmail.com> wrote:
>On Mon, Apr 9, 2012 at 4:47 PM, Tom Boutell <t...@punkave.com> wrote: > >> Let me be very clear about that... I am NOT proposing that <?php at >> the top be mandatory in a file loaded in code mode! I don't want to >> type it ever again outside of a template file, personally. See the >> title of the RFC. >> > >But again, how then do you intend to make it so that a pure-code file can >be called directly from the webserver on a host where the developer >doesn't >have access to most config options? This is a very common scenario that >cannot be ignored. If not a <?phpp tag, then *something* in that file has >to identify it as pure code otherwise this just isn't workable. > >Any INI option would be problematic because that would essentially cause >all scripts relying on the setting you didn't choose to break. And >unfortunately, recognizing a new file extension could pose problems for >people running on heavily restricted hosts that currently have PHP support >"built-in". While I would never host on one of those services myself, I >don't like the idea of suddenly alienating everyone who does. > >I'd totally be open to an alternative to the <?phpp tag that can withstand >scrutiny, but so far I haven't seen one. And absent that, there's no way >I >could support this, which really sucks because at least conceptually I >think it's a really good idea. If the default is "template mode" and the "<?php" tag is optional (at the top) in "code" mode there shouldn't be any problems. We don't need to change or leave out the tag entirely. Is there a problem with people being able to choose "template mode" or "code mode" as the default in the php.ini file if "template mode" is the default if not specified? Luke > >--Kris > > > >> >> On Mon, Apr 9, 2012 at 7:06 PM, Luke Scott <l...@cywh.com> wrote: >> > On 4/9/12 3:53 PM, "Tom Boutell" <t...@punkave.com> wrote: >> > >> >>I see why you want to allow <?php at the top to be optional in 'code >> >>mode,' rather than disallowed in code mode. But your purpose is to >> >>allow legacy code to be autoloaded without knowing in advance whether >> >>it starts with <?php or not. >> >> >> >>But that would probably lead in practice to the use of a single file >> >>extension for old and new class files. >> >> >> >>And that, in turn, would lead to source code being spewed to the >> >>browser for all to see if a perfectly respectable autoloader circa PHP >> >>5.3 runs into one of these new files. >> >> >> >>This is a much more significant security issue than some of those >> >>mentioned previously because perfectly well-written code would display >> >>this behavior if someone unknowingly drops a newer library into, say, >> >>the lib/ folder of a Symfony 1.4 project. Ouch. >> > >> > >> > So are you saying the starting "<?php" tag should be required in "code >> > mode"? >> > >> > If so, I'm ok with that as long as: >> > >> > - "?>" is forbidden >> > >> > - Text before the opening <?php tag (literal text or white-spaces) is >> > either ignored or throws an error instead of printing to the output >> buffer. >> > >> > If that's not what you mean, please clarify. >> > >> > Luke >> > >> >> >> >>It would be much better for that autoloader to just ignore the file >> >>because it has a new extension. This way the problem is immediately >> >>apparent: >> >> >> >>"Hey, my class didn't load, something must be up. Oh my PHP is old >> >>and/or this autoloader doesn't know about .phpc files, what are they >> >>anyway... google google... aha, I need PHP 5.x and an updated >> >>autoloader. Grumble. Okay." >> >> >> >>This is a much safer outcome. >> >> >> >>On Mon, Apr 9, 2012 at 6: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 (: >> >>>> >> >>>>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 >> >>> >> >>> >> >> >> >> >> >> >> >>-- >> >>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 >> >> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
