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