On Sat, Apr 14, 2012 at 5:04 PM, Anthony Ferrara <ircmax...@gmail.com>wrote:
> Kris, > > > It's worth noting that there are already two other similar RFCs that have > > been proposed and other people have expressed interest in this idea. > Most > > of the opposition on this thread has come from 2 people, one of whom has > > been mostly posting hyperbolic claims and scare tactics. There hasn't > been > > much substance for me to actually respond to. > > Yes, that's true. However, there have been a lot of people who have > stayed out of the conversation completely. I have been one of those > people. > You do realize you just proved my point, right? I said that, because only a small few people were actually participating in this thread, it would be completely disingenuous for one side or the other to claim to represent the majority opinion. The fact that you stepped in does not change that, though I'm glad more people are starting to share their opinions. > > I object significantly to a few points here. One is the concept of a > magic file extension. Why should a file behave differently just > because of a different extension? In general, extensions are human > readable clues to what's in the file. Yes, they are usually used for > mime type hints, but relying upon them feels dirty. And especially > baking in the reliance into the language really makes me feel dirty... > I'm not saying not to do it, but it's not exactly the cleanest > solution. > Anthony, *please read the thread before responding to it!! *I JUST addressed this a couple emails ago! There is no "magic" file extension. It's only a convention. Nothing more, nothing less. It is no different than how .php and .phps are handled. The convention dictates those extensions, but they're identified by the actual handler, as this would be. Understand? I'm sorry if I'm being a bit testy on this point, but it's REALLY annoying when people post patently false claims about what the proposal says. Seriously, what do you want me to do here? Argue in favor of something that my proposal doesn't seek to do in the first place?! Or agree that the proposal is bad because changing PHP to be parsed based on file extension is bad, even though my proposal *does not propose that*?! I welcome criticism, but please let that criticism at least actually *apply* to the proposal I'm making! You're literally attacking a completely fictitious idea that is not a part of this proposal. The .phpp extension is a convention; you can name it whatever the hell you want, though, so long as you've got the right handler set. Just like with .php and .phps. Seriously, *please don't make me repeat myself again on this*, ok? As you might have noticed from all the bold letters in the last few paragraphs, that tends to be a pet peeve of mine lol. =) > However, please not another feature that is dependent upon > configuration. The past usages of the php.ini file have lead to > really difficult problems to solve, tons of boilerplate code and > inconsistent behavior. Over the past few versions of PHP, those > offending ini settings have been slowly phased out. That's not saying > ini won't effect behavior, but it won't effect runtime behavior. > Sure, you can disable extensions, but you don't change how files are > executed (like register_globals and magic_quotes did). Yes, you can > effect internal behavior (like session settings), but that isn't > exposed to PHP for the majority of usages. Please don't introduce new > behavioral settings. > *sigh* Again, that's not what this proposes. In fact, this RFC doesn't even mention php.ini. I think there is a separate RFC that does, but it's in a different thread and is not in any way affiliated with this one, though they do share a similar topic. So far, you and I are in complete agreement. I've already spoken out as to why the .ini approach is troubling to me. I've also made it clear that the file extension isn't literally what's determining the type, but is rather just a convention. Are a lot of you confused on this point? If so, I suppose I could clarify the wording of the RFC to eliminate confusion. To reiterate, both of these things you've criticized are NOT a part of this RFC. > > And the extension being ini dependent (as you said in this very email > I'm replying to) would very much fall into that realm... > > While I'm replying, I might as well reply on the whole RFC: > > As far as the "problem" indicated, I don't see that as a problem that > PHP itself needs to solve. I see that as more of a lint problem. And > in fact, PHPCS (CodeSniffer) includes rules that allow you to check > for this exact sort of thing. So if you're concerned with people > abusing `?>` in files, just add a rule, and you're done. And if > you're just complaining about typing 5 characters `<?php` at the top > of files, I think that's a bit short sighted. It's a major language > change, and introducing inconsistent behavior to save typing 5 > characters... > I *partially* agree. In fact, my initial reaction to the calls for scripts without a <?php tag was the same as yours. But then I saw how many people were actually arguing in favor of this, and there are some valid points to be made. However, I didn't like any of the RFCs that were already out there, essentially for the same reasons you described, so I created my own as an alternative approach. I don't necessarily see the current behavior as a "problem," per se. But I do believe that having the ability to create a pure code stack would be beneficial and serve as a good selling point to outsiders when PHP 6.0 comes out, though I think some people's expectations as to how wide the use-case for this should be are somewhat unrealistic. > > Additionally, it will completely defeat extension restrictions > installed on a number of servers (to prevent a misconfiguration of the > server from accidentally serving php files unprocessed). Sure, you > could simply add .phpp to that list, but that's a massive > communication effort to adjust millions of servers... And I'm not > sure it's worth it in this case... > That's why this is not being proposed on PHP 5.x. This is targetted for PHP 6, where it's a foregone conclusion that there will be major differences that will require across-the-board changes on servers that choose to adopt it, and I'm sure it would be a gradual process. > > Finally, let me quote something from the RFC: > > > After all, the key benefit of a .phpp file is being able to reliably > > segregate your model layer from your template/view layer without > > having to worry about HTML code being “sneaked-in” from > > someplace deep within an include stack. > > Since when is it up to the language to enforce a particular > *pattern*'s constraints? That's exactly what code reviews, lint tools > and automated analysis is for. No feature is ever going to prevent > abuse from your code. After all, if you disallow directly outputting > HTML by file type, what's to stop it from doing a simple echo? > As I said (I think the RFC says this, too), echo/print/etc statements are NOT disallowed by this. The only things disallowed are <?php and ?> tags, that's it. The second change is that code is parsed as PHP instead of HTML, so pure HTML code would throw the same error it would now if it was within a <?php tag. And that's it! This isn't about preventing abuse or improving security. Again, please refer to the other RFCs for that. The scope of this one is much more limited and much more focused on aiding the developer. There's already precedent for this, too: Take a look at the include and require statements. By your logic, when don't we simply get rid of require? After all, it does the exact same thing that include does. It just blows-up in your face if the include fails. Why do you suppose we have such a distinction? Because some developers, myself included, would rather the code blow-up in our faces instead of failing gracefully in certain circumstances. If I was creating a true MVC application, this would make it a LOT easier for me to ensure that no ?> code got accidentally mixed in with the stack. If it did.... KABOOM!! This is also why I tend to use require instead of include nearly 100% of the time lol. Granted, it does ultimately come down to a question of preference. That's also why I offered the compromise (which I'm STILL waiting on SOMEONE, ANYONE to respond to, btw!). But there is precedent for this sort of distinction in PHP. > I applaud the effort, but please keep an open mind to the replies. > Don't make the same mistake that I have made in the past and get > defensive and hence blinded to the actual flaws that were presented. > Sure, some will be from people who didn't even read the RFC, but in > general, give people the benefit of the doubt. You'd be surprised how > helpful people can be if they don't feel attacked... > You're right, and like anyone else, I too can become overly defensive at times. However, in this case, I've proposed a compromise that NOT ONE SINGLE PERSON has even acknowledged-- much less responded to-- yet. Not one. People (including yourself) are attacking this RFC for having provisions that don't even exist or that are in other RFCs written by other people. I've addressed certain criticisms, only to have those identical criticisms raised again as if I had said nothing at all. It's VERY frustrating! I am open to new ideas and I am open to modifying the RFC to address certain concerns without gutting it completely. But what I am NOT open to is repeating the same back-and-forth over and over and over and over again because people are just skimming instead of actually *reading* what's been said. I'm not here to defend someone else's RFC and I'm not here to answer the same question a gazillion times while nobody bothers to actually read it. If you look through my recent posts, you'll notice that the overwhelming bulk of my frustration is directed at that one thing. So please, PLEASE, check to make sure something hasn't already been said before posting it! And if you're concerned about something, please, PLEASE, make sure that you're not getting this RFC confused with someone else's! I promise you, my mood will improve dramatically if people would just start doing that. =) --Kris > Anthony > > > > Regarding the specific comment, it was in response to a far-overused > cliche > > on this list whenever new ideas are posted; "That's not important, we > > should be working on other things." It always annoys me when people post > > that, because it doesn't amount to any specific criticism and it assumes > > that talking about one thing prevents us from working on another. > > > > > >> > > >> > Please refer to my previous posts on the matter. For me at least, > this > >> > isn't about saving a 5-byte tag. It's about making it easier to > >> structure > >> > your code with a stronger separation between design and backend > function. > >> > > >> > > >> > >> As to this point it doesn't fall in line with what PHP is. PHP is meant > to > >> be > >> embed-able. It's meant to be easy. It's meant to make the development > >> process fast and simple. > >> > > > > This RFC doesn't change any of that. > > > > > >> > >> It isn't meant to be difficult or painful. It isn't meant to create > >> impenetrable > >> separation between code and design. That won't make anything easier on > >> the user. If anything you've just created a border they now have to > figure > >> out > >> how to cross over. Why are you insisting that this separation isn't > already > >> easy enough to achieve with PHP? Because to me it always has been easy. > >> I've been doing it for 6 years. I haven't found anyone that thinks the > >> process > >> is incredibly difficult or hasn't been able to achieve it in reasonable > >> time. > >> > > > > PHP has evolved over the years and its usage has evolved. I would > > encourage you to read the background section of the RFC, as I've already > > addressed this. > > > > The reason why I'm not responding to certain points is because I've > already > > addressed them in the RFC and, as a general rule, I try not to be dragged > > in to arguments where I'm essentially just repeating myself over and over > > again. If somebody can't be troubled to read the RFC and my posts before > > responding to them, then why should I assume they'll read it if I repeat > it > > x number of times? To me, THAT is what would actually constitute a waste > > of time. > > > > > >> > >> > > >> > I think you guys are stressing-out about the file extension idea a > little > >> > too much, and here's why: What I'm proposing with regard to the .phpp > >> > extension is a convention, nothing more. The actual differentiation > will > >> > be in the form of a separate handler that's essentially identical to > the > >> > current one except for the few minor changes outlined in the RFC. In > >> other > >> > words, the .phpp extension is NOT mandatory. Just as .php is a > >> convention, > >> > so is this. If you want to give it an entirely differnet extension in > >> the > >> > webserver configuration, you can do so. The .phpp is just what the > >> > convention calls for, but in actuality what matters is that it's just > a > >> > different extension than what you're using for regular PHP scripts. > >> > > >> > So I would urge everyone to calm down on this point, because I'm not > >> > proposing anything new in terms of how file extensions are used. I > would > >> > liken it to the difference between .php and .phps. You can give them > >> > whatever extension you want, so long as they're different. Make > sense? > >> > > >> > >> I would urge that if you're going to make a suggestion you address in > >> an objective > >> manner what the pros and cons of said suggestion are and not take a > biased > >> view > >> by weighing both sides of the facts evenly. > >> > > > > You clearly have your own biased view on this issue, so I'm not sure why > > you feel it appropriate to lecture others on having their own biases. > > > > I'm the one who proposed this and I'm the one who's advocating it. Of > > course I'm going to be biased in favor of it. I feel I did a good job of > > addressing these pros and cons in the RFC itself, which is where they > > should be. The discussion is where I actually explain why I believe the > > pros outweigh the cons, not simply restate the two. Again, I don't like > > repeating myself (and yes, I realize the irony of that statement given > how > > many times I've said it lol). > > > > > >> I believe for the most part a lot of voices have weighed in on the > >> cons of this idea > >> as well as the pros and the cons seem to be clearly outweigh any of the > >> pros. > >> > > > > As I said, most of the criticisms have come from a very small number of > > vocal people. Their opinions are valid, but it would be inaccurate to > > assume they're the majority. The voting process will ultimately > determine > > that. Some people, like myself, believe that the pros outweigh the cons. > > You obviously disagree. > > > > > >> > >> The supporting argument for that fact being that I'm seeing this RFC > >> being rewritten > >> as regularly as I take my morning coffee. > >> > > > > Huh?! Look at the changelog on the RFC. The only change I've made so > far > > since the initial draft was changing the status from draft to discussion. > > I haven't "rewritten" it even once, so I'm not sure where that comment > > came from. > > > > > >> I respect everyone's right to their opinion and I'm willing to hear > >> anyone out that is > >> willing to consider both sides of the situation objectively and without > >> biased. > >> > > > > I'm glad you respect everyone's right to their opinion. As do I. But I > > would ask you to reconsider your claim of being "unbiased," because > you've > > clearly demonstrated a solid bias against this even on a core conceptual > > level. It might be more accurate to say that you're, "open-minded" about > > it, but "unbiased" would be at best misleading. I'm certainly not > unbiased > > on this, and with all due respect, neither are you. So let's not pretend > > that we are. > > > > Also, I am increasingly frustrated over the fact that much of what I've > put > > forth appears to be repeatedly ignored by people commenting on this; i.e. > > raising issues that have already been addressed, etc. Most importantly, > > I've offered a third solution that would allow for per-file sanity > checking > > instead of per-stack, which is exactly what the most vocal critics have > > been demanding, and yet so far not one person has so much as acknowledged > > this, let alone offered any sort of response (for or against), despite > the > > fact that this has to be at least the 4th time I've repeated it here. > > Again, I don't like repeating myself, so please read what's already been > > said here and on the RFC before posting. And tell me what you think > about > > the compromise I suggested. The only thing more frustrating than having > to > > repeat oneself is putting out an olive branch in hopes of finding common > > ground, only to be ignored and subsequently accused of not trying to find > > common ground. *grumble* > > > > Please review these things, *then *post a response. Thank you. > > > > --Kris >
