On Apr 7, 2012, at 9:04 AM, Tom Boutell <t...@punkave.com> wrote: > 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
Why would you need to? With it on or off <?php would work like it did before: With it off (how it is now): - Text before <?php would be printed to the output buffer. - ?> ends php code and prints text between it and the next <?php tag or the end of the file. With it on: - <?php is optional and must be first in the file. White spaces before <?php are ignored and text before throws an error (perhaps white space should through an error). The shebang line for the cli sapi is the only exception. - ?> is explicitly forbidden. If classes start with <?php and leave out the ending ?> this should be fine. Most classes written with PHP 5+ comparability do this anyway. The only way I see this not working is for PHP short tags where PHP is used as a template language. A lot of people decide to use other template engines though, like Twig. I personally avoid short tags on large projects and use them only on small quick and dirty projects. Luke (Sorry, I keep forgetting to hit reply all) > > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
