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