On Sat, Apr 14, 2012 at 11:29 AM, John Crenshaw <johncrens...@priacta.com>wrote:
> Sent: Friday, April 13, 2012 3:39 PM > > On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw < > johncrens...@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. > As I said, this is NOT an inherent conflict. What it comes down to is *how* this "compilation", as you put it, is taking place. > > > > 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. > No, it doesn't. I've already explained how your claim that it creates "2 languages" is inaccurate. Simply repeating a false claim won't make it any more true. That, too, is a logical fallacy. Also, if you claim that something is "inherently destructive to the PHP development community," you're essentially saying that it will single-handedly destroy the PHP community, which is an utterly ridiculous statement no matter how you look at it. That's what I mean when I refer to cheap scare tactics. > 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. > And? That same argument could be made to argue that the header() function should be eliminated. As we've seen in the separate threads about LFI, the developer has to take some responsibility for not writing bad code. The problem you mention is *easily *avoidable. If you're mixing your autoloaders/handlers/etc in such an ad hoc fashion, then using that with .phpp would not be a good idea. Also, I've repeatedly offered a third solution that would alleviate concerns raised about these specific cases, but you two have yet to even acknowledge it, let alone respond to it. That suggests, to me at least, that you're more concerned with just shooting this down on any grounds you can find rather than actually work towards a solution that works. > > 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. > Again, that's simply not accurate. Do some research on this, as there are many, MANY established, well-known methods for dealing with these issues already out there. The MVC approach that I outlined is just one of them. PHP is far less rigid than you seem to be giving it credit for. > > > 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 seem to be the one who has "missed it." I would refer you to my previous paragraphs on the subject. This doesn't create a separate language, nor does it do anything even *resembling *that. It's just a slight variation to the parsing behavior, nothing more. The language itself is completely untouched by this. > > 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. > Please refer to this article: http://en.wikipedia.org/wiki/Weasel_word > > > 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. > If you see that as somehow condescending, then I would respectfully suggest that you grow a thicker skin. What you're complaining about is a very narrow problem, but you're portraying it as if it encompasses "most" (see "weasel words," above) PHP frameworks/libraries/etc, which you appear to be basing solely off of your own anecdotal experience. Pointing out this inherent flaw in your reasoning is neither "condescending" nor unreasonable. And again, you keep using wildly hyperbolic terms like, "massive architectural overhaul," and, "forces a division in the community." Neither characterization is applicable to this proposal. The fact is, some frameworks can be made to work with this, others can't. If yours can't, then don't stress about it. There's no rule saying you have to use this file type if what you're doing is not compatible with its purpose. Oh and at the risk of repeating myself, I still have yet to hear any response from either of you regarding the compromise approach I offered. If you're actually genuinely concerned about making this compatible with more frameworks and not just trolling, you should stop ignoring my attempts to reach at least some common ground on this. --Kris > > > 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 > >
