On Sat, Apr 14, 2012 at 8:40 PM, Anthony Ferrara <ircmax...@gmail.com>wrote:
> Kris, > > > 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. > > All I'll comment on this is that it works both ways. Just because > there appears to be vocal support for this, doesn't mean that the > majority of developers support it. That's what a vote is supposed to > solve. So let's get past the "number of people who want feature x" > argument, and look at the technical details of the proposal only > (which is what this discussion phase is supposed to be)... > True. Of course, I've never claimed that a majority supports it. A number of people do want "feature x" as you put it and that's the reason I created this RFC. What the majority thinks, your guess is as good as mine. I'm content to let the RFC process handle all that. > > > 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. > > Actually, I did read the emails. And if I'm not mistaken, you said > this (and I quote): > > > 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, if it's not a configuration setting, how is the parser supposed to > determine which way it should handle an include call? How should it > determine how a request should be handled? Realistically, the only > way this can work in the real world is with a configuration setting. > And I say the real world, because it would need to work at the PHP > entry point, not at the server itself. Otherwise, we'd be coupling > the application instance to the server configuration. Which would > basically make this feature a non-starter for shared hosts (and hence > the majority of PHP users). So, in practice, the only way it could be > implemented is as a configuration setting. > > If you see another way of it working, please elaborate. Because at > this point, I haven't seen any technical aspects of the RFC that > clarify it any further. If you do clarify it, please by all means > let's discuss that. But as of now, I can only go on what I see and > read, and that points to a config setting. > 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. 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. 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. ;) > > > 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. > > That's part of the problem here. The proposal doesn't say much. > Sure, it points out a theoretical solution, but no technical one. > Without the details of how it would be technically implemented, I'm > not sure what you're expecting the discussion to be based on... > The technical details will be added as the conversation progresses. We were making some good progress on other threads, but then this one just dived into a tailspin and became dominated with "this will destroy PHP!" nonsense. I'll see about adding some additional details to get the conversation back on track, but I don't want to get too specific on points where people are still debating the best approach. The primary characteristic of this RFC is the fact that this occurs on a per-stack basis and is not dependent on INI settings or other ad hoc solutions, though some of the specifics on that are still pending (keep in mind I only drafted this RFC a couple days ago). It might have helped to include links to the related RFCs to give people context, but I didn't want to risk people getting them confused (even though that seems to have happened anyway lol). > > > 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. > > Well, if the current behavior is not a problem, what is this supposed to > fix? > Did you just read the first sentence of that paragraph then ignore the rest?! Because everything after "per se" answers your question already. > > > 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. > > While that's a valid point, I'm not sure if it's a strong one. Even > with major versions there should be a good reason to break > compatibility and the way things work. If there's a good reason, by > all means let's do it. But as of yet, I have yet to see what I would > consider good justification for this. > True, but this does not break compatibility with anything. All scripts as they're written now will be compatible with this, period. As far as server configs go, keep in mind that the same thing happened when we switched from PHP 4 to PHP 5, so this is not without precedent. For example, chances are Windows servers running Apache will need to change "php5apache2_2.dll" to something else anyway. ;P > > 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! > > So in your own words, it won't actually solve the problem it's set out > to solve (prevent outputting from model files). > 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. > > > 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. > > 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. 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. > Since there's *literally* no difference between outputting data via > <?php and echo (check the opcodes, it's for all practical purposes > identical to echo), you're preventing one but not the other. So > you're not saying "die if this file tries to output". I'm not saying > that would be good, but at least it would be consistent. > That's an over-simplification actually, because you're forgetting one key element of the RFC: The PHPP files are parsed as PHP, not HTML. In other words, "$a = 5; print $a;" in blah.phpp will output, "5", while the same code in blah.php will output, "$a = 5; print a;" if it's not within a <?php tag. For the above reason, I have started to lean towards the other suggestion of using a different keyword instead of a <?phpp tag, but I'm still on the fence with that one. If we could get the conversation back on track, I should be able to make up my mind on that, but for now I'm too busy defending the whole concept of this (which wasn't even my idea in the first place 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. > > Where's this compromise? Is it in the RFC? I didn't see it... > No, it's in the Internals thread. It's just that nobody seems to have actually *read* it. > > > 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. > > I read the RFC before my original reply. I did not read all of the > discussion in this thread before replying (I skimmed most, and read > the last few replies). I based my commentary off of your prior email, > and the RFC. > 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. 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 > > > > >
