RE: [PHP-DEV] [RFC] New .phpp File Type for Pure-Code PHP Scripts

Sent: Friday, April 13, 2012 3:39 PM > On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw <johncrenshaw@priacta.com> wrote: > > > > > > > > On top of this, there's an argument that you're not addressing: most > > > > 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 entangled, > > > the very notion of a pure PHP stack is just incompatible. So your best 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 of trying > > to put together valid markup using string concatenation? (Or worse, manipulation > > 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 could 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 because it was a first class template language. Web development is, at the end of the day, metaprogramming. > > After a lot of thought I've decided that I'm strongly opposed to the nature 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. This > > 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 clear to > > anybody at first, which will lead to mass proliferation of .phpp libraries which > > are like poison to any unsuspecting PHP user foolish enough to try to use 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 development community." I stand by that. It segregates the community and effectively 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 takes is one callback, one event, one autoloader, one error handler, one anything, and the entire application system falls apart because one library decided 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 .phpp 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 their 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 changes to > the language in this RFC. The only difference is a new file type that parses PHP > without the need for a <?php tag and with ?> raw HTML code not being permitted > 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 somewhere that doesn't have a rigidly defined inclusion and operation structure. This 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 that figured it didn't need templating on the other side. The two sides will be 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 that 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 working 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 problem > incorporating this if they chose to do so. The "all or nothing" mindset you'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 looseness 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 use a terrible nasty templating structure, the new ones make heavy use of autoloaders and MVC. > 4. For the gazillionth time, there is no BC break in this RFC! The language 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 introducing an entirely new class of code that is not only incompatible with older code, it is even incompatible with code written for the same version of PHP, because once you start into .phpp you can't get back out. > 5. Using cheap fear tactics like "any unsuspecting PHP user foolish enough" 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 terrified), but I've articulated the reasons why bad stuff happens, and other developers have raised many of the same concerns. Finally, your main argument for this is that the current way allows bad architecture. 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. If 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 you probably have a bad rule). 3. Not everyone agrees with your assessment of the badness of this architecture. In fact, the structure of most current MVC frameworks would suggest that most developers have a decidedly different perspective on this (which is 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 file must know something substantial about the internal operation of every file 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 appropriate file extension to match. This is an egregious violation of encapsulation. 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 + echo, and library compatibility problems. This is what I was talking about when I said you were bombing London to stop a jaywalker. Maybe there's a debatable code structure issue that some people don't like with including templates from code files, fine. But, if fixing it causes this sort of collateral 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