Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:60023 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64096 invoked from network); 16 Apr 2012 21:59:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Apr 2012 21:59:45 -0000 Authentication-Results: pb1.pair.com smtp.mail=tom@punkave.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=tom@punkave.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.160.170 as permitted sender) X-PHP-List-Original-Sender: tom@punkave.com X-Host-Fingerprint: 209.85.160.170 mail-gy0-f170.google.com Received: from [209.85.160.170] ([209.85.160.170:33771] helo=mail-gy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 98/E0-05733-F469C8F4 for ; Mon, 16 Apr 2012 17:59:44 -0400 Received: by ghbg2 with SMTP id g2so3136299ghb.29 for ; Mon, 16 Apr 2012 14:59:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-gm-message-state; bh=6PV5c3rhG36AaDDaHe6sKFlKBmVoiCnvplyFROKqLvk=; b=BCepOmU+sYGGB6N9ln50on3FpC8oGY7BjuUiAdvqVoYxtEo74lUana010HiumGYLJK Xvv1AWqfk+A6XFnHHQISUsl1MCvVRLC0DWWNcBW2nKdceurh1LDgRA7FJdj0NFpb/tKc FDZT7tsge7euX7GuFxZFmjrnGKBz1vXhF3TcuTq63V1P3QDHw8wbZRZ59XwS6WVa2NVn hDrhLcugY0CYlJujYpK8p30tSIthkk8eQNqXICOsNAf91nVBOEu0Icq0u0yadGxf8DuJ xVfqfK6IVf23pRk5MpX4TTN2bUUuW8ckiv0nTEO+7RgaL92UFpyWYZbtfwwnBnMzDRk8 87Aw== MIME-Version: 1.0 Received: by 10.101.143.32 with SMTP id v32mr3790363ann.34.1334613581234; Mon, 16 Apr 2012 14:59:41 -0700 (PDT) Received: by 10.101.57.14 with HTTP; Mon, 16 Apr 2012 14:59:40 -0700 (PDT) In-Reply-To: References: <4F876943.8030105@gmail.com> <4F877777.8050806@gmail.com> <4F8782CC.8030205@gmail.com> <4F87C9B0.4080809@gmail.com> <4F8AA9CF.6000003@gmail.com> <4CF91067-DBC4-4CD7-AF91-1814A6999EEF@punkave.com> Date: Mon, 16 Apr 2012 17:59:40 -0400 Message-ID: To: PHP Internals Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlNBD859gA6riZADeMUUmQJgZONIxKlKzuBoE3BrYjFw7FhC+IbUPXpALFC+CWUWgrBxqKB Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts From: tom@punkave.com (Tom Boutell) Kris, you have been talking recently about allowing for a mode that permits the inclusion of .php from .php... something (whatever we're calling this middle mode's recommended file extension). I think having three modes is overkill, but some people think having even two modes is overkill, so I'm prepared to live with having all three modes (traditional PHP, "pure" PHP that is allowed to include traditional PHP, and "purest" PHP that is not allowed to include traditional PHP). After all, I don't have to use "purest" mode if I choose not to do so - and I suspect most library authors won't because they want to write code that can include whatever the user wants it to. That's their choice and mine, and there's really no reason to deny you the option of "purest" mode. And one can make the argument that while, as you say, model code should never include a template, controller code (or classes in the view layer that manage templates) should invoke templates. That would give a better rationale for having all three types. However, your RFC still does not address allowing all three and currently includes very negative language about the middle option. A second issue is that your RFC calls for file extensions to be explicitly recognized by PHP itself, which is something many people have objected to because the file extension may be unavailable or irrelevant depending on the environment. That's why my RFC addresses the file extension issue as a strongly recommended convention, not a language feature, and provides keywords that can be used to implement that convention (and really ought to provide options for the various SAPIs as well, so entry points can be pure PHP if desired). I think it's probably time to write an updated version of your RFC so we can figure out if we're developing common ground here. 2012/4/16 Kris Craig : > > > 2012/4/16 Tom Boutell >> >> Also, Kris's proposal requires that an additional flag be tracked all >> the way down through the stack of requires and includes from the point >> where pure mode is first encountered, remembering that we're in pure >> mode. Note that this flag cannot be a global variable because .php >> files that were loaded before this .phpp file are still permitted to >> load things, including when acting as autoloaders on behalf of .phpp >> code... my head hurts. This cannot be the cleanest way to solve the >> problem. >> >> 2012/4/16 Tom Boutell : >> > Oh I see. Yes, this is one of the reasons I don't like the "pure can't >> > include non-pure" idea. >> > >> > Another reason: you can't write generic algorithms. PHP 5.4 has much >> > improved support for anonymous functions, so we should see an increase >> > in libraries that take a few functions as parameters and carry out an >> > operation via those functions. But what if one of those functions >> > requires something from a .php file? Whoops, I guess it's not a >> > generic sorting algorithm library I just released, it's a "generic >> > sorting as long as none of your functions touch a .php file" algorithm >> > library. And good luck figuring this out when it happens. >> > >> > Kris has pointed out that you could still load a .php file via a >> > function that was defined earlier in a .php file that later includes >> > .phpp. But this just means that, like my RFC, his RFC contains a >> > compromise about strictness. It's just that his compromise is more >> > confusing and less likely to be understood before the user gets >> > frustrated and declares the whole thing not worth messing with. I >> > think ".phpp files don't contain but can require and >> > include files that do" is a much clearer compromise, one that will get >> > us what we want (an ever increasing percentage of .phpp files) without >> > making enemies and generating opposition along the way to that better >> > place. >> > >> > On Mon, Apr 16, 2012 at 9:24 AM, Arvids Godjuks >> > wrote: >> >> 16 =C1=D0=D2=C5=CC=D1 2012=9A=C7. 16:09 =D0=CF=CC=D8=DA=CF=D7=C1=D4= =C5=CC=D8 Tom Boutell >> >> =CE=C1=D0=C9=D3=C1=CC: >> >> >> >>> These tools already strip > >>> to >> >>> support rolling in a .phpp file unmodified. Unless I am missing >> >>> something? >> >>> >> >>> Sent from my iPhone >> >>> >> >>> On Apr 15, 2012, at 5:30 PM, Arvids Godjuks >> >>> wrote: >> >>> >> >>> > I posted the bellow text in other thread, but i should have it pos= t >> >>> > here, >> >>> > so i'm reposting it to this thread. >> >>> > >> >>> > Well, it's time for me to remind about the techique many use (and >> >>> > some >> >>> > frameworks provide it out of the box) - the application file >> >>> > concatination >> >>> > to speed up file loading. >> >>> > Yii framework provides a Yiilite.php file for this, that includes >> >>> > mostly >> >>> > used core classes in one big file.that loads much faster and is us= ed >> >>> > for >> >>> > production. Any other framework has user extentions or other type = of >> >>> > solutions for this to speed up the application, and it makes reall= y >> >>> > big >> >>> > difference. >> >>> > So there is a good question - how the hell in a MVC framework woul= d >> >>> > i >> >>> > combine my models, controllers, components and other stuff that wi= ll >> >>> > definetly be as in .php so in .pphp. And not every file will be >> >>> > cached >> >>> > like >> >>> > that - some will remain as distinct files even in production. >> >>> > >> >>> > The further discussion goes the more questions there is and less >> >>> > answers >> >>> > there are. >> >> >> >> >> >> Yes they obviously do, but that's not what I'm concerned about. >> >> What I'm concerned is that code from .php and .pphp files get's mixed >> >> in >> >> together - template engine related stuff is used as much, as do >> >> controllers, >> >> session handling classes and bunch of other stuff that by definition = is >> >> .pphp stuff, but the template stuff is .php and it includes templates= . >> >> So >> >> basically everything just has to fall back to the embedded PHP mode t= o >> >> work >> >> and we have no gain from the proposal what so ever - it just becomes >> >> useless. >> >> >> >> That's not counting other issues that people and I have been voicing >> >> and to >> >> be honest, I never saw a reply to any of it. Maybe there is a reply t= o >> >> all=9Athose=9Aquestions, but they are under wall of text that usually= goes >> >> in >> >> reply - that just discourages to read it at all. >> > >> > >> > >> > -- >> > Tom Boutell >> > P'unk Avenue >> > 215 755 1330 >> > punkave.com >> > window.punkave.com >> >> >> >> -- >> 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 >> > > The RFC is vague on these points because they haven't been determined yet= , > though I am starting to lean toward the include/require parameter option = for > includes. > > To Tom's point, these questions have already been addressed.=9A Basically= , > there will be a third type that's on a per-file basis, designed to mitiga= te > the concerns that have been expressed over making this accessible to peop= le > using certain frameworks that utilize tangled architecture.=9A The per-st= ack > option will be more suitable for applications that have been designed fro= m > the ground-up to use a seperated architecture.=9A Though the per-file one > really wouldn't be useful for me, enough people believe that it will be.= =9A So > since there are valid use cases for both options, I'll include them both. > > Please refer to my post on Pierre's thread.=9A I outlined an idea for how= this > could work syntactically.=9A Please post your responses here though so th= e > thread will be easier to follow. > > --Kris > --=20 Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com