A thoughtful suggestion. But the trouble with a php.ini setting is that you can't tell if it is enabled when writing your class file. That makes it impossible to write portable libraries. The keywords would always be available. And no one has to type them outside of an auto loader (:
Sent from my iPhone On Apr 7, 2012, at 11:46 AM, Luke Scott <l...@cywh.com> wrote: > On Apr 7, 2012, at 7:00 AM, Tom Boutell <t...@punkave.com> 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. >> >> .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. > > Tony I think your idea has some merit. If it were up to me I'd remove > <?php all together. It really is bad practice to mix HTML into code. > > But I feel that adding new keywords is not the way to do it. > Personally I'd like to see a php.ini setting to disallow the ending ?> > tag and assume .php files just have PHP code. The starting <?php tag > would be optional. White space would be ignored and non-white space > characters before <?php would throw a fatal error. > > Doing it this way would disallow bad practices but still make existing > PHP scripts compatible. > > I think that doing that would be quite reasonable. Those who complain > about it likely ignore industry best practices anyway. This option > could be turned off by default at first, made default later, and then > ?> be deprecated all together. > > So with this option enabled ?> is forbidden, <?php is optional, and > the text before <?php is handled differently - white spaces ignored, > text before throws an error (unless it's a shebang line in cli mode). > > Hopefully that made sense. Does this sound good to you? > > I'm sorry you had to endure such a nasty troll. I am so sick of self > righteous bullies who think they know it all. > > Luke > >> >> 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 >> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
