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

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. > > 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. 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.... 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. 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. 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 > 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 > >