Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:60009 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 38176 invoked from network); 16 Apr 2012 19:21:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Apr 2012 19:21:42 -0000 Authentication-Results: pb1.pair.com header.from=kris.craig@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=kris.craig@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender) X-PHP-List-Original-Sender: kris.craig@gmail.com X-Host-Fingerprint: 74.125.82.54 mail-wg0-f54.google.com Received: from [74.125.82.54] ([74.125.82.54:34892] helo=mail-wg0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 40/EB-05733-5417C8F4 for ; Mon, 16 Apr 2012 15:21:42 -0400 Received: by wgbfg15 with SMTP id fg15so862352wgb.11 for ; Mon, 16 Apr 2012 12:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Be6oVjvCpXowfgZv641f8DyGTnEARwkjTIj7PQZzvUQ=; b=MJDtq+yppN9tlN9vfGu1z3S2wxP1r+ac+jR7wmAH4yhj1gaxhfCzvhuFhhFBRYwvLn hUH5x+RRZA/wkKGVsR53w42pZt0mpP0vb3FOGd2Jq80VQK+lED+71eCb/U6SkxicZJ33 q6Q3R9oBtDY65vGK88ffm3D9NcpIuboaHtuHGSFWHpZ+iadtg3eb4TV2bzt5GKPJVo4a NmcoknCACRAud/yNksZu7gn4VAX8vWyb3Qb6KSUCocvShklJZCAJ13CTe9k/J9RnTK+S SNmVWjuZmIIDHn6mXEGn/N4OnjPKIvrkclQEjnxe3tSMQQcTxZfkkm5rfwPwMRy+3f4w pT7A== MIME-Version: 1.0 Received: by 10.180.91.168 with SMTP id cf8mr13928906wib.0.1334604098737; Mon, 16 Apr 2012 12:21:38 -0700 (PDT) Received: by 10.223.1.82 with HTTP; Mon, 16 Apr 2012 12:21:37 -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 12:21:37 -0700 Message-ID: To: Tom Boutell Cc: PHP Internals Content-Type: multipart/alternative; boundary=f46d0438934738965e04bdd0bb58 Subject: Re: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts From: kris.craig@gmail.com (Kris Craig) --f46d0438934738965e04bdd0bb58 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable 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 =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 post > >>> > 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 use= d > for > >>> > production. Any other framework has user extentions or other type o= f > >>> > solutions for this to speed up the application, and it makes really > big > >>> > difference. > >>> > So there is a good question - how the hell in a MVC framework would= i > >>> > combine my models, controllers, components and other stuff that wil= l > >>> > 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 i= s > >> .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 to > 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 to > >> all those questions, 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. Basically, there will be a third type that's on a per-file basis, designed to mitigate the concerns that have been expressed over making this accessible to people using certain frameworks that utilize tangled architecture. The per-stack option will be more suitable for applications that have been designed from the ground-up to use a seperated architecture. Though the per-file one really wouldn't be useful for me, enough people believe that it will be. So since there are valid use cases for both options, I'll include them both= . Please refer to my post on Pierre's thread. I outlined an idea for how this could work syntactically. Please post your responses here though so the thread will be easier to follow. --Kris --f46d0438934738965e04bdd0bb58--