Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59928 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90972 invoked from network); 14 Apr 2012 18:29:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Apr 2012 18:29:43 -0000 Authentication-Results: pb1.pair.com header.from=johncrenshaw@priacta.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=johncrenshaw@priacta.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain priacta.com designates 64.95.72.241 as permitted sender) X-PHP-List-Original-Sender: johncrenshaw@priacta.com X-Host-Fingerprint: 64.95.72.241 mxout.myoutlookonline.com Received: from [64.95.72.241] ([64.95.72.241:29919] helo=mxout.myoutlookonline.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9C/AF-33137-512C98F4 for ; Sat, 14 Apr 2012 14:29:41 -0400 Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E20A4416D38; Sat, 14 Apr 2012 14:29:38 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1F894416E87; Sat, 14 Apr 2012 14:29:38 -0400 (EDT) Received: from MAILR001.mail.lan ([10.110.18.28]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Sat, 14 Apr 2012 14:29:37 -0400 To: Kris Craig CC: Matthew Weier O'Phinney , "internals@lists.php.net" Date: Sat, 14 Apr 2012 14:29:08 -0400 Thread-Topic: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts Thread-Index: Ac0ZrQovvm/xDKzXQdqojediyvNe3gArsxaw Message-ID: References: <4F876943.8030105@gmail.com> <4F877777.8050806@gmail.com> <4F8782CC.8030205@gmail.com> <13.6A.35770.615388F4@pb1.pair.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts From: johncrenshaw@priacta.com (John Crenshaw) Sent: Friday, April 13, 2012 3:39 PM > On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw wrote: > > > > > > > > On top of this, there's an argument that you're not addressing: mos= t > > > > template engines in PHP either directly consume PHP template files.= .. > > > > or "compile" templates into... PHP template files. As such, sooner = or > > > > later, you'll have a class that includes a PHP template file, and > > > > that's where things break for me in this proposal. > > > > > > > > > > They don't break because nobody in their right mind would ever try to > > > include a .phpp file in a framework like that. If its stack is so en= tangled, > > > the very notion of a pure PHP stack is just incompatible. So your be= st bet > > > on a framework like that would be to stick with .php. > > Um, so if you aren't using any form of template engine whatsoever, what= are you > > proposing? You're saying we should all go back to the good ol' C days o= f trying > > to put together valid markup using string concatenation? (Or worse, man= ipulation > > of DOM classes?) No thanks. IMO this is a bit like blowing up London to= stop a > > jaywalker. > > That's a logical fallacy; i.e. your contention relies on the premise that= , if this > doesn't work with every single framework known to exist, then it doesn't = work with > any template engine whatsoever. That's just patently ridiculous and coul= d not be > further from the truth. I think you missed the problem entirely. All but a tiny handful of template= engines (and ALL of the template engines that are fast and powerful enough= to use as the view component for a site) compile into PHP templates. Once = something is included in the way you propose there is no longer ANY viable = view option. The only way to output anything at that point is with strings = and echos. The entire reason PHP became popular in the first place is becau= se it was a first class template language. Web development is, at the end o= f the day, metaprogramming. > > After a lot of thought I've decided that I'm strongly opposed to the na= ture of > > this proposal at a fundamental level. It isn't that I just wouldn't use= it. This > > proposal is inherently destructive to the PHP development community. Th= is > > effectively attempts to split PHP into two languages. Current PHP isn't= really > > compatible with the proposed ".phpp" version of PHP, in the sense that = you can't > > safely use both in the same code base. Unfortunately this will not be c= lear to > > anybody at first, which will lead to mass proliferation of .phpp librar= ies which > > are like poison to any unsuspecting PHP user foolish enough to try to u= se one. > > This isn't just a BC thing, it is really a permanent language fork. > > A few points: > 1. How exactly will this single-handedly "destroy the PHP community"? I = will give > you bonus points for creative hyperbole, though. That's not what I said. I said it is "inherently destructive to the PHP dev= elopment community." I stand by that. It segregates the community and effec= tively divides PHP into two languages that both seem (on the surface) to be= the same thing. Problem is they're not really compatible. If they are used= together one will eventually cause the other to break in confusing ways. In this thread we've had people suggest that library developers should use = this .phpp stuff. That's EXACTLY the problem I'm worried about. All it take= s is one callback, one event, one autoloader, one error handler, one anythi= ng, and the entire application system falls apart because one library decid= ed that it didn't need template mode. If the division were clear it wouldn't even be so bad, but it's not clear. = Everything is called PHP, and this is getting marketed as just "use the .ph= pp extension if your file doesn't use templating". It is devilishly subtle,= and the average library developer who decides to do this won't realize at = all the hell that they are about to release on the web developers who use t= heir library, because if their library is in the call stack at all, for any= reason, any attempt at templating will die. > 2. This does NOT split PHP into two languages. In fact, there are no cha= nges to > the language in this RFC. The only difference is a new file type that pa= rses PHP > without the need for a raw HTML code not being perm= itted > within that file type's stack. Again, bonus points for wild hyperbole...= . Yeah, you missed it, which ironically is exactly my concern. I refer you to= two paragraphs earlier. You've said before that no sane developer would include .phpp files somewhe= re that doesn't have a rigidly defined inclusion and operation structure. T= his is exactly the problem. Most MVC frameworks now heavily use autoloaders= and other patterns (plugins, listeners, error handlers, etc.) that do NOT = have a rigid inclusion structure. And that's all OK (wonderful in fact, it = allows for incredible things). This syntax change though forces a division = in the community with these MVC frameworks on one side, and any library tha= t figured it didn't need templating on the other side. The two sides will b= e at constant war, because their code will never be safe to use together. > 3. Current PHP is perfectly compatible with this, as would be many if not= most > implementations (some might require more work than others). And those th= at aren't > aren't being forced to use this new file type in their projects anyway. = I think > what's at issue is the particular framework that you are accustomed to wo= rking with > would not mesh well with this. But that's a very narrow subset of PHP. = The > language itself and probably most implementations of it would have no pro= blem > incorporating this if they chose to do so. The "all or nothing" mindset y= ou're > expressing is not logical. Um, wow. That's just condescending. I'm tempted to not even respond do that= . I've used too many frameworks to count and ranging all the way from the l= ooseness of "on the metal" code down to the rigid structure of Magento and = Zend. There isn't a single framework I've worked with (not one) that could = start using .phpp short of a massive architecture overhaul. The old ones us= e a terrible nasty templating structure, the new ones make heavy use of aut= oloaders and MVC. > 4. For the gazillionth time, there is no BC break in this RFC! The langu= age is not > being redefined as you're characterizing it and .php files will continue = to behave > exactly as they do now. Yes, you are right. There is no BC break. It's worse than that. You are int= roducing an entirely new class of code that is not only incompatible with o= lder code, it is even incompatible with code written for the same version o= f PHP, because once you start into .phpp you can't get back out. > 5. Using cheap fear tactics like "any unsuspecting PHP user foolish enoug= h" and "poison" > only serves to cheapen this discussion and erode your own credibility. > > --Kris Look, these aren't "cheap fear tactics". Yes, it's scary (I know I'm terrif= ied), but I've articulated the reasons why bad stuff happens, and other dev= elopers have raised many of the same concerns. Finally, your main argument for this is that the current way allows bad arc= hitecture. Let me address that specifically: 1. It is not PHP's mandate to make sure everyone uses good architecture for= their code. 2. Enforcing architecture rules is really more a job for PHP CodeSniffer. I= f CodeSniffer can't enforce it, then your developers won't be able to keep = track of whether their new code breaks the rule either (which would mean yo= u probably have a bad rule). 3. Not everyone agrees with your assessment of the badness of this architec= ture. In fact, the structure of most current MVC frameworks would suggest t= hat most developers have a decidedly different perspective on this (which i= s that view rendering should be encapsulated, but it doesn't really matter = where in the call stack the encapsulation actually occurred). 4. There's an architectural elephant in the room. To make this work every f= ile must know something substantial about the internal operation of every f= ile it includes, and every file that those files include, and all the files= that might get included with it in the stack, and much choose the appropri= ate file extension to match. This is an egregious violation of encapsulatio= n. 5. The structure advocated by your RFC is an anti-pattern. To make it work = you have to throw out MVC, listeners, plugins, callbacks, and/or templates,= and/or have to introduce monolithic lists of includes, string escaping + e= cho, and library compatibility problems. This is what I was talking about w= hen I said you were bombing London to stop a jaywalker. Maybe there's a deb= atable code structure issue that some people don't like with including temp= lates from code files, fine. But, if fixing it causes this sort of collater= al damage then really, just leave it. John Crenshaw Priacta, Inc. -- I am using the free version of SPAMfighter. We are a community of 7 million users fighting spam. SPAMfighter has removed 839 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len The Professional version does not have this message