I'm sorry that you decided to go forward with this non-productive attitude. I will give you my last detailed answer and then I'll be forced to lock down this thread. This discussion is going nowhere, since you demonstrate no willingness in hearing everyone objections, you don't want to form a group to discuss your proposal and you don't want to follow PHP-FIG process to push forward your ideas.
This is open source, noone is paid to stay here and/or give you a response; you where met with explanations and a request to follow the proper, published workflow for PSRs, and instead you decided to go on all alone, creating repos and demanding us for technical review of your solo job. There's a reason for which we require working groups to be formed around PSRs: those are complicate matters, because generalizing and standardizing even the smallest bit of code is a hard problem. You need multiple point of views to discuss and pour over a simple interface before being able to say "this is worth as a PSR and will promote interop". Look at PSR-11, it's a single interface with two bare-bone methods, it required months of discussions and previous work (see container-interop) but it was hugely successful. > This was not retaliation. As I mentioned, I have not done well at explaining things to Larry, so I wanted to make sure other people benefited by my effort which would otherwise likely have been wasted. So you were not retaliating, you are considering speaking to Larry "wasted time". Again, this is not respectful behavior, especially toward a CC member which is in the nominal position of giving you advice and opinions on what you put in front of the PHP-FIG. > What? Who did I dismiss? I dismissed no one. I only saw that Matthew had become silent and presented that the issue I presented was unsolved, so I decided to solve it. Matthew didn't step down from the discussion, his last answer is from 5 days ago and in the meantime you received a barrage of answers and objections; he also already answered that point for you, and you reset the discussion. He said "That makes a HUGE assumption, however, that the message instance knows exactly how to construct the stream instance composed into it." This is a huge blocker (one of many others of the same kind) for your proposal as a standard IMO. He's a developer with a huge experience, he's behind Laminas and at least half the work behind all the HTTP PSRs, so I would hold his opinion in high regard. > Wow. This itself is a misrepresentation. I have responded to each of the points by everyone about my use of PSR except for Larry, with reason. Again, "with reason". You're giving yourself the right to ignore and dismiss, but anyone that doesn't immediately counter your answers is wrong or proving you right. > I didn't know that until afterwards. This (partially) excuses your past behavior. Now you know, and we will not consider you acting in good faith if you will continue forward with using names that are associated to the PHP-FIG. I want to point to you the fact that, if this wasn't voluntary open source work, this would be the point where lawyers would get involved. But that's not who we are, and not what we want to do. We just want to state clearly that, since you don't want to follow our processes and push forward your ideas through us, we don't want to see affiliations where there isn't none. And you're still welcome to propose your idea through the proper channels if you want. > I encourage you to really read my responses and present me with counter arguments rather than telling you read through the thread in a cursory manner and decided I'm a bad actor. Again, you're accusing others (me in this case) of acting in bad faith without proof. I've read this thread and the chat thoroughly, spending more than an hour to understand it all. And I've pointed out (twice now) where I see bad behavior from you. As I said before, I will now lock this discussion, since it devolved on quote bickering (on all sides) and it's not going anywhere. Il giorno lunedì 12 luglio 2021 alle 18:38:12 UTC+2 [email protected] ha scritto: > >> - you answered to Larry patronizing him (supposedly in retaliation), >> without dignifying him of a proper response (the "Larry, if two others here >> would second and third your opinion, I will explain why you are wrong." >> answer) >> > This was not > > This was not retaliation. As I mentioned, I have not done well at > explaining things to Larry, so I wanted to make sure other people benefited > by my effort which would otherwise likely have been wasted. > > - you claimed multiple times that you were busy building stuff, hence >> valuing your time, but you dismissed others when they weren't able to >> respond to you in a timely fashion, hence not valuing theirs >> > What? Who did I dismiss? I dismissed no one. I only saw that Matthew > had become silent and presented that the issue I presented was unsolved, so > I decided to solve it. > > >> - you rudely accused PHP-FIG members of lying and being ignorant just >> because they were disagreeing with you >> > As far as I know, I only accused Ian of lying. Being ignorant is another > matter that is fully acceptibly caused by lack of time. > > >> - you ignored and dismissed multiple accounts from multiple people >> discouraging you to use the "Standards Group" and "PSR" names >> > Wow. This itself is a misrepresentation. I have responded to each of the > points by everyone about my use of PSR except for Larry, with reason. > > >> - you dismissed the possible implications of such course of action, >> which I consider not taking any responsibility for your actions >> > I analyzed implications - to which no one has contended my analysis. > > > On this last two points, I would like to remind you that "PHP Standards >> Group" was the original name of the PHP-FIG, and the founders abandoned it >> just because of the sheer amount of backslash from the PHP community at >> large; so that TWO different reasons to not use this name; >> > I didn't know that until afterwards. > > >> so I, again, encourage you to not use those names, to avoid confusing >> users, but instead to have a name to call your own, if you really want to >> push your ideas outside of the PHP-FIG. I hope you can reconsider that in a >> show of good faith, so that we can go on and start discussing on technical >> merits only from this point further. >> > > I encourage you to really read my responses and present me with counter > arguments rather than telling you read through the thread in a cursory > manner and decided I'm a bad actor. > > >> Il giorno lunedì 12 luglio 2021 alle 02:01:10 UTC+2 [email protected] ha >> scritto: >> >>> I've updated my PSRs with notices about FIG PSRs >>> >>> I've released PSR 102 >>> https://github.com/PHP-SG/psr-102 >>> >>> And the Implementation >>> https://github.com/PHP-SG/psr-102-implementation >>> >>> From the beginning, I wanted to solve the "bill" to "bob" issue. Then, >>> I wanted technical feedback on my PSR 100 and 101. Presently, I would very >>> much appreciate technical feedback on my PSR 102 and the implementation. >>> On Sunday, July 11, 2021 at 9:06:15 AM UTC-7 [email protected] wrote: >>> >>>> Adam, >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> 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/4ddaaa38-00cb-40c2-b7c8-2d31b5f0bd44n%40googlegroups.com.
