On Apr 9, 2012, at 10:44 AM, Ralph Schindler <ra...@ralphschindler.com> wrote:
> Hey Tom, > > An idea, why not overload require/include with a second parameter that simply > enforces an include mode. For example > > // in some autoloader (include, requires, and *_onces) > include $pathToFile, INCLUDE_MODE_PHP_ONLY; > > This would tell the parser/executor to start in PHP mode and never leave it, > that way, ending tags would throw a runtime/execution error. > > Other constants and behaviors could be: > > INCLUDE_MODE_PHP_START; > INCLUDE_MODE_PASSTRHOUGH_START; (the current and default behavior) > > This would have the least amount of impact on BC, and seeminlyg would be a > friendly change to the lexer/syntax. > > Thoughts? If this were to happen: - I would prefer much shorter elegant constants. - A constant for suppressing warnings thrown by include without suppressing warnings/errors by the actual file -- I think we can all agree @include is counter productive since it does much more that suppress warnings thrown by include (even parse errors!). Luke > > -ralph > > > > On 4/9/12 12:23 PM, Tom Boutell wrote: >> Also, your objection - that 'require_code' is confusing - would most >> likely be an issue for a handful of people who write autoloaders. >> Those clean PHP class files are almost always autoloaded. >> >> On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell<t...@punkave.com> wrote: >>> I see what you're saying, but you're proposing a new keyword to >>> include code that does what plain old 'require' does now (assuming >>> it's not a nice clean class file that is being included). Which means >>> that valid code today is busted code once this feature comes out. That >>> seems like a very hard sell. >>> >>> On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott<l...@cywh.com> wrote: >>>> On Apr 9, 2012, at 9:16 AM, Tom Boutell<t...@punkave.com> wrote: >>>> >>>>> It sounds like you are proposing to gradually kill the use of PHP for >>>>> templating entirely, which I don't think is something people would >>>>> vote for. >>>> >>>> I'm not saying that at all. I'm saying that PHP code should be clearly >>>> separated from template code.<?php should be optional at the start of >>>> the file and IF a keyword should be added it should be for templates >>>> and short-tags. >>>> >>>> 99% of modern PHP code is going to be classes that start with<?php >>>> and omit the ending ?> (since PHP 5 due to how easy it is for white >>>> space to end up on the tail end of a file). this is even the case with >>>> procedural code. >>>> >>>> Half the PHP frameworks out there have their own template engine >>>> because they can do a lot more than what short tags offer. Example: >>>> Twig offers template inheritance. >>>> >>>> Introducing a keyword for PHP code without the<?php tag is >>>> impractical. It makes much more sense to have a keyword for templates. >>>> >>>> For non-template code the starting<?php tag should always work as it >>>> has before for backwards compatibility. The difference is you cannot >>>> use ?> and text before the opening<?php tag is either ignored or >>>> throws an error. >>>> >>>>> I sometimes use perfectly good older frameworks that do use >>>>> .php files for templating in a reasonable way, and I'm one of the >>>>> advocates for migrating away from starting everything with<?php. I >>>>> would have to vote against it myself. >>>> >>>> And those files can be included with something like require_template >>>> or you can turn off the option in the ini file. >>>> >>>> The point is in EITHER MODE a php file that starts with<?php will >>>> work as it did before. The new mode would just disallow you to break >>>> out of PHP code with ?>. >>>> >>>>> There's no reason to kill good >>>>> code that passes its tests just because it uses inline HTML. I won't >>>>> even know I have that code in my project from some third party library >>>>> until I find out the hard way. No, just no. (: >>>> >>>> I'm not trying to kill anything. In fact what I'm proposing would be a >>>> smooth transition to something that is already done. The difference is >>>> at some point you won't be able to do this: >>>> >>>> <?php >>>> class Object >>>> { >>>> public function output() >>>> { >>>> ?> >>>> Print me! >>>> <?php >>>> } >>>> } >>>> >>>> I cringe every time I see this. There is no excuse since we have >>>> here/nowdocs. >>>> >>>> For people that use PHP as a template there can be other options. I'm >>>> not totally against a new keyword, but I am against a new keyword for >>>> including normal PHP code. It just doesn't make sense. No matter what >>>> you name it (require_code, require_file, require_path) it's damned >>>> confusing. If you did it the other way around its much clearer: >>>> require_template. >>>> >>>> With require_template you're also free to expand template >>>> functionality while keeping code clearly separated. >>>> >>>>> I did propose one new keyword, but by proposing one keyword with a >>>>> future-friendly syntax instead of four new keywords I'm attempting to >>>>> help with the pollution problem. >>>> >>>> It's not as much as adding a keyword as it is what keyword you're adding. >>>> >>>> I hope the way I've explained things makes sense. >>>> >>>> Luke >>>> >>>>> >>>>> On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott<l...@cywh.com> wrote: >>>>>> Tom, >>>>>> >>>>>> As I've said before I don't think new keywords are the answer. They >>>>>> will just pollute the language even further. >>>>>> >>>>>> I also don't think an ini setting is a bad thing either. It is often >>>>>> used in PHP as a way to transition from way of doing things to >>>>>> another. First you introduce it with it being off by default, then on >>>>>> by default, then deprecate the old behavior. It's quite normal in >>>>>> PHP's history. >>>>>> >>>>>> In another email someone mentioned doing two rfcs. In both cases are >>>>>> we talking about removing<?php ? Because it's become somewhat >>>>>> confusing to keep track of what is being talked about. If that is the >>>>>> case, continue reading. >>>>>> >>>>>> I would prefer the starting<?php tag be optional rather than removed. >>>>>> Just explicitly forbid the ending ?> tag and treat text before the >>>>>> opening<?php tag differently. Perhaps ignore it (rather than print) >>>>>> or throw an error. >>>>>> >>>>>> That is at least how I would prefer the "code" mode as most >>>>>> non-template files only start with<?php. It allows for backwards >>>>>> compatibility. >>>>>> >>>>>> If you must add keywords it should be something like require_template >>>>>> NOT require_code/require_file. Templates are the exception, not the >>>>>> norm. >>>>>> >>>>>> Luke Scott >>>>>> >>>>>> On Apr 8, 2012, at 9:32 AM, Tom Boutell<t...@punkave.com> wrote: >>>>>> >>>>>>> I have written an RFC proposing backwards-compatible support for >>>>>>> source files without an opening<?php tag: >>>>>>> >>>>>>> https://wiki.php.net/rfc/source_files_without_opening_tag >>>>>>> >>>>>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure >>>>>>> what the requirements are to get it added to the "Under Discussion" >>>>>>> session and get the ball rolling formally. Please enlighten and I'll >>>>>>> do whatever is required. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>> >>> >>> >>> >>> -- >>> 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