I will say, Ian, you are the only one here from FIG who has been intentionally disrespectful. Your second posting has confirmed suspicions of mine. Not only have you impugned my character on discord and lied about the summary of events in this thread, but you are now attempting to misdirect even further. So, I will dissect.
> You're posting to the FIG list, so you telling Larry, Buster, myself and > others why we are mistaken has the side effect of also telling FIG. > This is complete misdirection. Let's see what you are attempting to misdirect: a quote of yours from the first posting: """ where you tell FIG, which has gotten buy-in from various maintainers to use the same interfaces, just how wrong they are. """ Again, I did not tell FIG, I told Larry I would explain how his opinions in a specific message were wrong. But, now, you are trying to misdirect people again: that some how, by individually interacting with people on this list after I made that statement, and that because that series of interactions has included Larry, You, and Buster, that the meaning of my passed statement about Larry's email should actually be interpreted as "telling FIG ... how wrong they are". What I have seen is that everyone who seconded Larry's posting actually each had their own caveats that I had to separately address. Btw, @Buster, sorry for the informal response, I was responding to what I saw as a hen pecking by multiple people while under time constraints, and as far as I knew at the time, you were just some programmer who happened to be on the mailing list. Ian, I suspect that your rapid response to my rather lengthy response to you served as an attempt to cover my response to yours where I point out many traits that characterize you as a bad actor. The rest of your email, while no longer misdirecting, is diverting, but I will address it anyway since other may be interested. > Given that you believe that Laravel and Symfony could make use of your > spec, it's worth approaching those maintainers directly, as neither are > members of FIG. > > If you're clear about your goal here (e.g. framework adoption within X > timeframe), there may be better ways of achieving that goal than posting to > the list. > @all I have been clear at the outset. I want a standardized (not de facto standard) way of changing the response body in middleware. When Matthew stepped out, and in view of the silence of FIG, in order to achieve this, I had to make my own. Under the consideration presented by Matthew that the request handler might not be appropriately a factory (this is an opinion I don't hold), I reconsidered, and realized that the whole App level could be standardized, and this would seemingly be the ultimate goal of FIG. Because of this realization, I continue to post on here about PSR 102, which can be extended with PSR 11 and PSR 14 to create a fully functional app that does layering (middleware, outerware), events, and acts as a service container. I think this level of standardization would be extremely beneficial for PHP. I also think that my LayeredApp PSR 102 very fully addresses the needs of frameworks. I was expecting some technical feedback. Even if it was the cursory feedback that I built in to my PSR 100 implementation README, that the problem I present is actually a problem of Liskov substitution principle violation. > > Ian > > On Sun, Jul 11, 2021, 10:54 AM Adam Frederick <[email protected]> wrote: > >> >> 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 [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/0b42760e-4fc9-4223-b546-51f8d03776bbn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/php-fig/0b42760e-4fc9-4223-b546-51f8d03776bbn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/f0bfaaa0-5a61-4dc3-8ff7-cd58cc6cd5f6n%40googlegroups.com.
