On Sat, Apr 14, 2012 at 11:20 PM, John LeSueur <john.lesu...@gmail.com>wrote:
> > On Sat, Apr 14, 2012 at 11:55 PM, Kris Craig <kris.cr...@gmail.com> wrote: > >> On Sat, Apr 14, 2012 at 10:16 PM, Anthony Ferrara <ircmax...@gmail.com >> >wrote: >> >> > Kris, >> > >> > > As discussed on other threads, PHPP files that are called directly >> from >> > the >> > > webserver are handled by the SAPI handler and thus don't need any >> special >> > > identification. >> > >> > Except that they do. Right now, SAPI handlers just invoke PHP. So >> > there would need to be some way of communicating the difference over >> > the SAPI. And in most of the SAPIs, that's not really practical. So >> > for most SAPIs, it would require running two instances for each site, >> > one for "regular" php, and one for the new phpp. Given the problems >> > that this can ensue, I think that there's an issue with that concept. >> > >> >> I'm not convinced of that, but again the technical specifics of how that >> would be handled are still up in the air. If you have a better idea >> regarding how to implement that, please share it. It would be illogical >> to >> suggest that all viable approaches have been discounted since no real >> brainstorming on this has happened yet; just people crossing their arms >> and >> saying, "No that won't work, go away." >> >> I appreciate your skepticism, but if you really want to be helpful, please >> try to offer some suggestions of your own so we have more to brainstorm >> with. >> >> >> > So again, we're back to configuration... >> > >> > > If they are called as includes, this would be handled >> > > either through a new keyword or a <?phpp tag at the top of the .phpp >> > file. >> > > The latter approach is my preferred choice but I'm keeping an open >> mind >> > on >> > > this question since there have been some differing opinions on that. >> > >> > Now I'm even more confused. So instead of making a <?php less file >> > entirely (just source), you're just making a new syntax which >> > disallows ?>??? >> > >> >> Again, please catch-up on the conversation that has taken place up till >> now. You're basically turning the clock back on things that have already >> been discussed. Some of them are still open-ended, so right now you're >> really not helping. Also, keep in mind that this is why the RFC doesn't >> specify these things yet, because they're still being brainstormed and >> debated. >> >> >> > >> > > I didn't mention this in the RFC because I wanted to see if we could >> > reach >> > > some sort of consensus on that point here first, but instead the >> > > conversation has drifted onto wild tangents. These other threads were >> > > discussed literally just hours before this one so I just naturally >> > assumed >> > > that people who commented on this had followed them as well and knew >> > this. >> > > But in hindsight I can see how somebody seeing the RFC without having >> > > kept-up on recent Internals discussions could be confused by that, so >> > I'll >> > > go ahead and amend the RFC to clarify this point. But no, the file >> > > extension itself is not what determines how it's parsed. ;) >> > >> > Ok, let me ask for something then. Please demote this RFC to draft >> > status. Under discussion indicates (to me at least) that we're >> > discussing a particular technical solution prior to a vote. But if >> > there's no technical solution, and it's still changing (or supposed to >> > change), it should be in draft. Otherwise you're communicating that >> > it's ready to be considered when it's really not... >> > >> >> I disagree with that interpretation. To me, "In Draft" means that the >> core >> of the RFC is not complete and is thus not ready to be discussed. Once it >> is ready to be discussed, the status should be updated accordingly. The >> brainstorming phase regarding specific "how"s is part of that discussion >> in >> many cases. You'll notice that the status message is, "In Discussion," >> not, "In Debate." >> >> I would be open to creating a new status, perhaps "Planning Discussion" or >> something to that effect, but I do not believe the "In Draft" status would >> be appropriate for an RFC that already communicates the concept/idea being >> proposed, even if key details are still yet to be determined. >> >> >> > > Did you just read the first sentence of that paragraph then ignore the >> > > rest?! Because everything after "per se" answers your question >> already. >> > >> > Actually, it doesn't. The "problem" you identified isn't solvable by >> > this method. We already proved that. So my original question stands. >> > What is the problem that you're trying to solve. The rest of that >> > paragraph tried to defend the usefulness of the addition. That's not >> > a problem to solve. By clarifying this into a clear and concise >> > problem statement, you may be better results with the RFC... >> > >> >> You may disagree with the answer, but it is an answer nonetheless. If you >> don't believe it's something that is worth solving, that's your opinion, >> but my answer is what it is whether you choose to accept it or not. My >> original answer stands. I have no intention of repeating myself. >> >> If you want to learn more, please refer to recent discussions on Internals >> where this has been explored much more in depth. >> >> >> > >> > > I think you misinterpreted the "problem." The problem isn't output >> being >> > > sent to the browser via PHP commands/functions. The problem is raw >> HTML >> > > code being sent to the browser directly via ?>. In other words, >> > templating >> > > output as opposed to just all output. Obviously, preventing ALL >> direct >> > > output would be virtually impossible anyway and really wouldn't much >> any >> > > sense. The RFC also explains this. >> > > >> > > We're just talking about ?> here, not echo/print. >> > >> > Except that it's not sent to the browser via ?>... It's outputted just >> > like an echo would be. See: http://codepad.viper-7.com/9XbsOI >> >> >> In the PHP core backend, perhaps. But that's irrelevant. From a PHP >> script development standpoint, there is a distinction between PHP code and >> HTML code. Again, please refer to previous discussion on this as this has >> already been addressed. But to summarize, this is about *architecture >> *and >> *structure*, not core functionality. >> >> >> >> > >> > >> > >> I think that's a bit of a stretch. Include vs Require are very >> > >> different statements. They fail, not because something violated a >> > >> convention you want enforced, but because the application considers >> it >> > >> unsafe to continue without that file. So if you're expecting a class >> > >> to be there, and it's not, it would be literally unsafe to continue. >> > >> Hence the fatal error. >> > > >> > > >> > > Actually, they're really not. They both behave identically except for >> > the >> > > error_level thrown, unless I'm mistaken. >> > >> > I was saying Include vs Require is very different from php vs phpp... >> > Sorry, should have worded that better. >> > >> >> Ahh. The difference I was referring to was the argument concerning >> per-file vs. per-stack checking; i.e. the concern that raw output from >> somewhere deep in the include stack could cause a failure and, >> conceptually, why would a developer ever want their code to blow-up >> instead >> of just throw a warning and fail gracefully? The include/require >> precedent >> answers that question. >> >> >> > >> > > And again, which one to use comes down to developer preference, >> > philosophy, >> > > etc. Personally, I won't include a class or other script unless I >> know >> > it's >> > > there and I need it. Therefore, if it's not there, I want everything >> to >> > > blow-up. That's my philosophy, but to each his/her own. The point >> is, >> > I'm >> > > glad that require is there so that developers with this way of >> thinking >> > can >> > > construct their code accordingly. >> > >> > Except that if a file is not there, it's easy to assume that the >> > application will be in an inconsistent state. I can't really make >> > that same leap for ?> output... Not even close... >> > >> >> It depends on how you define "inconsistent state." Keep in mind that PHP >> is just one component of a successful AJAX implementation. Just because >> PHP itself isn't throwing errors doesn't mean that something else relying >> on the PHP output won't be. A key point of this is to make PHP play nicer >> in such situations with fewer rabbit holes. If ?> code is contaminating >> my model stack, it may not cause PHP itself to barf, but it will cause the >> framework as a whole to barf, and that's why I as a developer would want >> it >> to blow-up at this level instead. >> >> >> > > No, it's in the Internals thread. It's just that nobody seems to have >> > > actually read it. >> > >> > If it's important, make sure it's highlighted in the RFC. Otherwise, >> > don't complain if someone missed that email... >> > >> >> "Don't complain if [somebody didn't read your response]?!" Seriously?! >> Ok, so by your logic, I should move everything I've said here to the RFC. >> Sure, it might create one massively large document that ceases to be an >> actual proposal, but.... I'm sorry, what was the "but" again? The >> compromise was not RFC-ready, but it was specific enough to warrant >> discussion. Last time I checked, that's what Internals is for, after all. >> If people don't actually read each other's posts before commenting on >> them, what purpose does that serve? >> >> So yes, it's in the thread and you need to read it. Not everything in a >> listserv discussion belongs in an RFC (in fact, most of it doesn't). But >> there's a lot of background and other information that would be helpful to >> you, including the compromise idea I suggested. It's a discussion item, >> not part of the proposal; in part because nobody has bothered to discuss >> it >> yet lol. I've already explained it twice and I won't a third time, so >> please look it up. Rather than skimming for it, I would recommend you >> take >> the time to read through all the emails thus far. I know it's >> time-consuming, but if I can do it I know you can. It's a complex issue >> and one that's obviously important to you, so I think it would be worth >> your time to sit down and get yourself up-to-speed. >> >> >> > > That's probably where your misunderstanding of it was borne then. The >> > RFC >> > > is just an initial draft and it's based on several days' worth of >> prior >> > > discussions on various threads, including 2 other RFCs written by >> other >> > > people attempting to accomplish the same thing but in different ways. >> I >> > > just assumed that the same people who were discussing it on those >> threads >> > > would come here and help me brainstorm through some of the details, >> but >> > it >> > > looks like they weren't given a chance before the reactionary >> onslaught >> > > came. >> > >> > Again, then pull it out of discussion and into draft. In the >> > discussion phase, the RFC should be the canonical reference point >> > around the topic. And in this case it's not, so it's not really ready >> > for discussion phase. >> > >> >> Again, see above. ;) >> >> --Kris >> >> >> > >> > Thanks, >> > >> > Anthony >> > >> > > I do plan on updating the RFC with more details as we figure them out, >> > but >> > > in the meantime I would suggest you catch-up on what's been said so >> far >> > on >> > > Internals and the RFCs before commenting further. I would have >> suggested >> > > that in my previous email but I didn't realize that was the source of >> > your >> > > dissonance. If we can tone down the manufactured outrage and doomsday >> > > predictions for a bit, we can get back to hammering out these >> specifics >> > so I >> > > can complete the RFC and be confident that the best methods have been >> > > included with care and deliberation. >> > > >> > >> >> > >> >> > >> If you want to prevent going back and forth, update the RFC when >> > >> something is solved (or not). That way, there's a canonical place to >> > >> reference. Reading through tons of emails (especially when most of >> > >> the have an aggressive or rant tone to them) is not constructive... >> > > >> > > >> > > That's been the plan all along. Unfortunately, nothing has been >> solved >> > > because the thread was rather quickly hijacked by hyperbolic drama >> from >> > > people who hadn't even been following this discussion. >> > > >> > >> >> > >> > 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. =) >> > >> >> > >> I re-read the RFC again before this email, and from what I can see, >> > >> all my original points are still outstanding... >> > > >> > > >> > > See above. =) >> > > >> > > --Kris >> > > >> > >> >> > >> >> > >> Anthony >> > >> >> > >> > --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 >> > >> > >> > >> > >> > > >> > > >> > >> > > Since you're looking for input, specifically on the compromise, let's try > to figure out what's possible. The RFC proposes .phpp files that can only > include other .phpp files. Others want .phpp files that can include .php > files. There are two ways I can think of to accomplish this. > > 1. an ini switch. This is a bad idea, because it causes code written under > one setting to be impossible to use in the other setting. > 2. 3 file types. <?php, <?phpp, <?php~p (read: <?php almost pure) We'd > need something better than that last one, but what it means is that _this_ > file is pure php, but it may include an embedded script somewhere. > > Between those two options, I would choose 2. Just to be clear, if I had a > third choice, which was to make no change, it would be #3. > Option #2 is what the compromise I suggested was. Since there are already other RFCs out there and multiple people are pushing this, I created this RFC to reduce the scope (i.e. not make it about security or LFI, for example) and add consistency (i.e. doing it through the stack). The more I think about it, the more I lean towards an idea suggested earlier about introducing new keywords, though I would go about it differently. I would keep the .phpp as a naming convention and add a handler for it so it can be executed directly from the webserver without the need for a special tag. But for inclusion, the RFC doesn't really cover that yet because I haven't even made up my mind on what's best, though I'm starting to learn towards the keyword approach. > > The second thing that still needs nailing down as far as implementation is > how to determine parsing mode. If it has to be specified at include time, > then we're putting the burden on whoever writes the autoloader to know what > kind of file it is. If it has to be specified in php.ini, or in the sapi > configuration, then I'm putting the burden on the administrator. I want to > allow the developer who writes the file to specify its parsing mode. > > The two ways I see for developers to do so is to use variations on the > <?php header of the file, or by file extension. I prefer variations on the > <?php header, because file extension still depends on configuration in > order to work, so involves admins in the decision of how to parse the php > files that I write. > > <?php means just what it does now. > <?phpp means, disallow ?>, and error if there is anything before the > header. The RFC specifies an additional restriction, throw error if I > include file with <?php header. > <?phpo (open to suggestions for the text of this header) means disallow > ?>, and error if there is anything before the header. Hmm as in "PHP Open?" That could work. This goes back to the question of whether to do a tag, an INI setting, or a keyword. I'd already discounted an INI setting before I started the RFC, but I'm still on the fence regarding the other two. I was hoping the discussion could first focus on that question, since there's a lot of complexity involved and it'll take some rigorous back-and-forth for us to weigh all the pros and cons of each. But I do feel like we're starting to get back on track at least. =) --Kris > > > John >
