On Apr 7, 2012, at 10:00, Tom Boutell wrote: > That's a good point too. > > I think this is a better proposal: > > include_code, require_code, and require_code_once would work just like > include, require and require_once, except that the parser would start > out in PHP mode.
Those might be nice functions to have, but ... > .phpc is then just a convention for naming PHP files that start out > with code - a convention that autoloaders should respect, just as they > now respect the .php convention. "The user asked for the Monkey class, > and I see Monkey.phpc is out there; I'll grab that with > require_code_once." … I think this isn't quite as simple as you make it out to be. Any autoloader that cared about bc would have to have code like if(file_exists(.phpc)) require_code() else if(file_exists(.php)) require() else HCF() There's a reason everyone settled around a single extension, and not the plethora we used to have (php, phtml, php3/php4, others?). Even in the rainbows-and-unicorns world where everyone always has an opcode cache and suitably tuned stat cache, that extra call to file_exists that will likely happen while waiting for files to be renamed and tested still isn't free. Also, I'm willing to bet that in the unlikely event you chose to drop out of PHP mode to dump a block of HTML, the awkwardness of a sudden ?> without a leading <?php would make the discussions about whether or not to have a trailing ?> at the end of files look like hyper-civilized discourse in comparison. (Though, it might be an interesting discussion regarding making the hypothetical require_code only (directly) include files that are pure code, with no <?php ?> tags allowed.) Personally, I think the cognitive overhead the <?php ?> tags impose is pretty tiny. Yeah, you get weird errors sometimes, but once you understand what's going on, it's easy to fix (and generally easy to spot, if you're using version control). I really can't recall the last time it's happened to me and it took more than ten seconds to identify and fix. It's just one of the weird things about php. Every language has its rough edges, and in comparison, I really don't think this one even ranks in the top ten. There are plenty other parts of PHP that are far more awkward that could use addressing first (but won't, because of the bc break involved; haystack, meet needle). You could also view <?php at the top of the file as a sort of magic number indicating the file type (such as used in many binary file formats: gifs always start with GIF87a/GIF89a, java class files with 0xCAFEBABE, etc). It's unlikely a file that starts with <?php is anything but. -John > Putting this decision on the autoloader makes more sense because > autoloaders already contain assumptions about file extensions. They > have to in order to do their job of translating a class name to a > particular path somewhere. > > Folks who did not care for this functionality could then choose to > entirely ignore it. Class library developers who liked it would make > autoloaders available that honored it, freeing end-user developers > from thinking about it. It becomes self-contained, and people who are > writing old-school .php standalone scripts or pages are entirely > unaffected. > > On Sat, Apr 7, 2012 at 9:50 AM, John Bafford <dsha...@zort.net> wrote: >> >> On Apr 7, 2012, at 09:39, Tom Boutell wrote: >> >>>> 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 (: >> >> That "silly annoyance" doesn't seem to bother anyone who writes command line >> tools, which require the #! line specifying the command interpreter to be >> the first bytes in the file, with no leading white space whatsoever. >> Especially on unix systems (but also on the Mac), the file extension does >> not affirmatively indicate the file type or whether or not it can be >> executed. >> >> Also, from a CLI perspective, you don't want extensions in the names of your >> scripts, because then it causes problems/confusion/extra work if you later >> decide to change the language the script is written in. >> >> -John >> >> -- >> John Bafford >> http://bafford.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 > -- John Bafford http://bafford.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
