Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59543 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 76971 invoked from network); 9 Apr 2012 20:18:56 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Apr 2012 20:18:56 -0000 Authentication-Results: pb1.pair.com header.from=luke@cywh.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=luke@cywh.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain cywh.com from 209.85.220.170 cause and error) X-PHP-List-Original-Sender: luke@cywh.com X-Host-Fingerprint: 209.85.220.170 mail-vx0-f170.google.com Received: from [209.85.220.170] ([209.85.220.170:36565] helo=mail-vx0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 28/59-34074-F24438F4 for ; Mon, 09 Apr 2012 16:18:56 -0400 Received: by vcbfo14 with SMTP id fo14so2430010vcb.29 for ; Mon, 09 Apr 2012 13:18:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=rPkr2pCA6Y+sxe//qW0NDVVJhJgDXzagFCvoGoU6EfY=; b=NeBxXh/tMEY43biqlr22fGGvFekieTkL3mAHdtTqih5YLXC7URFrNS11p+IAVnNvEh 59F1aglkeZ7MdqkMZocIrG6yMtvIDGHQuVOOXjQy6VsT+nSlruEPX9O1spK5rki5ucgZ 1yBsi8CHIXIVOzK1e0z0zQd7SGRktW/ZJX2RSaJcSWpFly5zE9AXlAEAJjFL06Vt3OhT zmi0yKvKSYLiG3UC+mwPlQtXpoVMAUKfj8HnuKPu+VETzF79jKndliiut6MeL+3uy4BE m+qZXTWPUyy8pA7AqNjU7+JIKPLxJ/ZSFkO6biX9TDutuGH5YYETz+fRCG+rHz6gxVKs KZlA== Received: by 10.52.178.225 with SMTP id db1mr3355215vdc.26.1334002732612; Mon, 09 Apr 2012 13:18:52 -0700 (PDT) References: <-5877502932356715576@unknownmsgid> <-3647345967307864634@unknownmsgid> <4F831FAE.2030208@ralphschindler.com> <4775322189440202047@unknownmsgid> In-Reply-To: Mime-Version: 1.0 (1.0) Date: Mon, 9 Apr 2012 13:18:50 -0700 Message-ID: <-1600064027087554621@unknownmsgid> To: Tom Boutell Cc: PHP Internals Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnyYfVNFEtkpdgNWQyuuoNSCB7kymZuQ+pXAcqbaddt3gWeglU3NXwJ2y2zw/2wpWI67it/ Subject: Re: [PHP-DEV] RFC: source files without opening tag From: luke@cywh.com (Luke Scott) Tom, On Apr 9, 2012, at 11:26 AM, Tom Boutell wrote: > Ralph, you make good points. And Luke's opposition to my new keyword > is probably going to be shared by others (like Chris who just chimed > in). > > So the more I think about it, the more a set of constants that can be > OR'd together is a better idea than my associative array proposal. And > it's best to keep the original four keywords, adding the second, > optional parameter as a way of passing a combination of flags that > alter their behavior. > > Also that set of bits could include the 'once' and 'warning' flags, so > if you really want to just use the 'require' keyword and determine > dynamically which behavior you get, you can. So there are no new > keywords needed. > > Also, the presence of any bit that is not recognized by this version > of PHP should be an error. It's better to stop than to completely > misparse a file (: > > I don't think long-ish constants are a real problem since this > functionality would very likely be written just a few times in > autoloaders (as is typical in almost any project that would be > interested in .phpc files in the first place) rather than repeatedly > all over the place in every file (as with old-fashioned uses of > 'require', and various templating situations). > > I will revise the RFC shortly I do like constants. I would recommend: CODE TEMPLATE SILENT ...with some sort of prefix like INCLUDE_* or INC_*. I would very much like to have the ability to prevent just the warnings generated by include... Primarily for an auto loader. Include/require supports include path, file_exists does not. You can avoid a stat on include/require with APC, with file_exists you cannot. Perhaps that belongs in a different RFC... But if we're thinking of using constants it would be a nice thing to mention. Luke > > On Mon, Apr 9, 2012 at 1:51 PM, Luke Scott wrote: >> On Apr 9, 2012, at 10:44 AM, Ralph Schindler 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 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 wrote: >>>>>> On Apr 9, 2012, at 9:16 AM, Tom Boutell 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.>>>>> 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>>>>> 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>>>>> impractical. It makes much more sense to have a keyword for templates. >>>>>> >>>>>> For non-template code the starting>>>>> has before for backwards compatibility. The difference is you cannot >>>>>> use ?> and text before the opening>>>>> 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>>>>>> 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>>>>> 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: >>>>>> >>>>>> >>>>> class Object >>>>>> { >>>>>> public function output() >>>>>> { >>>>>> ?> >>>>>> Print me! >>>>>> >>>>> } >>>>>> } >>>>>> >>>>>> 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 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>>>>>>> confusing to keep track of what is being talked about. If that is the >>>>>>>> case, continue reading. >>>>>>>> >>>>>>>> I would prefer the starting>>>>>>> Just explicitly forbid the ending ?> tag and treat text before the >>>>>>>> opening>>>>>>> or throw an error. >>>>>>>> >>>>>>>> That is at least how I would prefer the "code" mode as most >>>>>>>> non-template files only start with>>>>>>> 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 wrote: >>>>>>>> >>>>>>>>> I have written an RFC proposing backwards-compatible support for >>>>>>>>> source files without an opening>>>>>>>> >>>>>>>>> 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 >> > > > > -- > 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 >