> I'll add my opinion in with Larry's to get closer to the requisite > threshold where you tell FIG, which has gotten buy-in from various > maintainers to use the same interfaces, just how wrong they are. While > grabbing a namespace on GitHub purporting to be, well, more than yourself. >
Not only is your use of sarcasm unprofessional, but you have lied: I did not purpose to tell FIG how wrong they were - only Larry and those who second him. > Hopefully you can understand the consternation arising when you decide to > skip that step after framework/middleware maintainers reply "yes, we > thought of that, and here's why we didn't go down that route." > I'm seeing a pattern here. This is quite ignorant on your part. I will explain for others, though. ""yes, we thought of that, and here's why we didn't go down that route.""" This did not happen. Go read the last email by Matthew and then my response to that. what happened was, in summary: Matthew: Oh, I finally think I understand what your issues are. Those are difficult issues, there are many things to consider about them, and it remains mostly unresolved. I'm hoping PHP 8.1 will allow us to resolve it better. [Ending with] "If that's the case, it's an open question" Me: Yes, the points you bring up are interesting. As counterpoints, you can do it X way, and you can also conceptualize it X way. Matthew: silence Me: well, I guess since no one is responding for a while to my valid counterpoints, I'll just have to make my own PSRs to solve the issue I brought up Perhaps people in the list don't understand where all this spawned from. So, I will quote myself from discord: right, but that means either 1. having a dependency within your middleware, or writing a PSR 7 implementation within your middleware [8:03 AM] both of which are problematic [8:03 AM] my perspective, from someone who just wants to write middleware that replaces "bill" with "bob" [8:03 AM] is that my middleware should have no package dependencies [8:04 AM] that I don't want to rely in injection [8:04 AM] and that I don't want to write my own psr 7 implementation just to change the body > With that in mind, which two frameworks do you intend to individually > convince to accept a PR exhibiting the functionality you're championing? > My mind is presently only on the perfection of the concept, not which frameworks may use it. The implementation of PSR 102 itself is fairly complex. But, in cursory inspection, I expect Laravel and Symfony could both implement it, since it (sort of) allows for the Symfony kernel event model, but using a different paradigm. I'll share something you posted to me on discord to give a better understanding to those reading the mailing list. """ iansltx — Yesterday at 11:52 PM Though, looking at the blog that shares an IP, and inexplicably a TLS cert, with your dot-org, I'm not sure you're operating in good faith here, given the ink poured a out how PSR-12 (and, I suppose, 1 and 2) have no place in FIG. """ What exactly are my bad faith motives? Like I said in discord, at the start, my desire was to replace "bill" with "bob", (because bills have no place in programming). My "blog" on CLRMO.com stems from me looking into the PSRs after ignoring them until just a little while ago. That you should dismiss me because I don't agree with PSR 12 really says something about you. I find that those who cling to standards like zealots and act as gate keepers reduce useful progress and lead to stagnant, inefficient status quos that serve their own unwillingness or incapableness to change. But, let's visit the very sane opinions I have about PSR 12 (*note, I didn't make a PSR XXX to replace PSR 12 b/c I think it is fine for most people*) 1. The standard of spaces makes sense for most big projects, but does not make sense as a standard for all projects. There is nuance to the tabs vs spaces debate which, as far as I have seen, in over 15 years of programming, has only been explained my me, here: https://clrmo.com/2021/07/spaces-vs-tabs/ 2. The standard of camelCasing is good particularly in frameworks and common tools, but it is a bad standard for apps. I explain this situation here https://github.com/CLR-MO/standard-coding#camelcase-vs-underscore and here https://github.com/CLR-MO/standard-coding#naming-exceptions 3. The placement of "{" on a new line for methods reduces the amount of useful code on the screen I can see at once. Even google presents this as an objective: https://google.github.io/styleguide/cppguide.html " - The basic principle is: The more code that fits on one screen, the easier it is to follow and understand the control flow of the program. Use white space purposefully to provide separation in that flow. " 4. Code styling doesn't matter that much. From the "blog" https://clrmo.com/2021/07/php-psr-12/ " - Different styles don’t matter so long as they are clear. The mixing of styles is mostly a problem when tabs and spaces are mixed, which can be prevented by a good editor. Programmers have been modifying each others code for decades and different, clear, styles have not prevented interoperability " 5. " - PSR 12 should not be a FIG PSR. The point of interoperability is whether some code will work in different environments. PSR 12 is for how programmers react to code, not for how the code functions in different environments. " All of these are valid points, but none of them led me to make a PSR to replace PSR 12, and I have no intention of doing so. Ian, I really do suspect that you are the sort of person that would cut me off at the knees to prevent my valid criticism. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/0b42760e-4fc9-4223-b546-51f8d03776bbn%40googlegroups.com.
