On Saturday, July 10, 2021 at 10:37:07 PM UTC-7 Buster Neece wrote:
> Adam,
>
> I know I don't chime in much here on the message boards, but I wanted to
> drop in and say hello, not necessarily in an official capacity but just as
> a developer in the community who's been a long-time follower of the FIG and
> the PSR standards.
>
> I very much understand the feeling of being up against a monolithic entity
> where it seems hard to get a word in edgewise or get your foot in the door.
> A lot of us feel this way when contributing to projects larger than our
> own, and for me personally, the fear of getting a negative response is what
> has kept me from submitting many contributions upstream to the projects my
> own software depends on. That feeling is real and valid, and it's
> imperative for the larger institutions to do what they can to remain
> approachable despite their size and momentum.
>
> In that context, there's nothing at all wrong with submitting ideas to the
> group here. Your ideas aren't without precedent, either, since I've seen
> numerous implementers of the PSR standards lump them together into singular
> libraries that cover multiple standards at once or extend the standards to
> be easier to use in their own context. By all accounts, even if your
> repositories didn't wind up as FIG standards themselves, they could
> continue to exist as standalone code and would likely be useful to a number
> of people looking to implement the combined standards in a friendly way.
>
> I also agree with Michelle in that it is unfortunate you were met with a
> response that you felt patronized your contributions. It's important that
> any interactions with participants in the FIG process be respectful and
> professional.
>
As I mentioned on discord
"Any way, thanks for trying to be helpful. I'm sure you guys get a lot of
"what about x" when the answer should be obvious, and that has partially
directed this conversation."
In the position of representing FIG, one will probably get a lot of obvious
questions. After years of dealing with mostly the same questions, one
becomes paradigmed into funneling all questions into one of the obvious
questions without attending to the details of the question
> By that same token, however, I'm not sure that messages like:
>
> > Larry, if two others here would second and third your opinion, I will
> explain why you are wrong.
>
>
There's really no great way to handle that situation.
Larry wrote a very long email. It would take me a long time to explain the
problems with it, and I've been busy building the prototype implementation
of my PSR 102. I've interacted with Larry on discord, and I've found he
often misinterprets me and misapplies concepts in an effort to correct me,
and that interacting with him can be tiresome. For instance, he tried to
compare the mistake {of adding a log setter method on PSR 3 rather than
using dependency injection} to my suggestion of having the Handler also be
a factory. Here was that interaction:
realize there are issues
Larry: "Use dependency injection" is enough of a de facto standard already
that there's little reason to specify it. And the alternative, setter
injection, is widely recognized as inferior. Only one spec included that,
PSR-3, and LoggerAwareInterface is, I would argue, recognized in hindsight
as a mistake.
Me: "I haven't used PSR 3, I'll have to take a look
[6:19 AM]
but, to mention what I was going to say
[6:19 AM]
1. potentially middleware will want access to factories before the
"process" method is called
[6:20 AM]
2. having an extension PSR would potentially create a mismatch of
expectation in middleware(edited)
[6:21 AM]
right, slightly different situation with the logger though
[6:22 AM]
with the middleware, you already have handler being injected
[6:22 AM]
the question is about what that handler can do
[6:22 AM]
it's not exactly the case of $middleware->setFactory()
[6:23 AM]
since the middleware already expects the handler
[6:23 AM]
@Crell
[6:24 AM]
even further, there is an oddity of set handler for logger
[6:24 AM]
whereas, a framework uniformly handles IoC dependency injection
[6:25 AM]
it would have to have a special case for handling something implementing
LoggerAwareInterface
[6:25 AM]
it would have to check if the class implemented it, and then it would have
to call the setter
This is an example of misapplication of concepts in an attempt to correct
me. But, as I already mentioned, Larry also spent two days thinking my
issue was empathy for those who didn't know how to use DI.
I could have ignored Larry, which is often what the "professional" thing to
do is. Or I could have been more ambiguous about my requirement to respond
and said "Does anyone else feel this way"? But, even that second option is
bad, b/c I don't want people who feel and don't think to second Larry and
make me spend time responding.
> ...convey that level of respectfulness or professionalism either.
>
Yes, it was intentionally curt with a purpose. I could go on a tangent
about how being overly nice can make bad programming communities, but I
wont.
> I think the friction you're feeling with the FIG group doesn't stem from
> the content of your suggestions themselves, but rather the manner in which
> you presented them, which was in the form of a GitHub organization named
> "PHP-SG" with standards that presented as numbered "PSR"s.
>
No. The friction was occurring in discord way prior to my decision to even
make those PSRs. I would posit the friction stems from what I talked about
with getting stuck in paradigms owing to answering the same questions over
and over.
> What does "PHP-SG" stand for? Absent any clarifying information on my
> side, and given the organization's only contents are these new "PSR"
> standards, I'd have to assume it stands for something like "PHP Standards
> Group".
>
I didn't want to promote myself in putting out PSRs, so my option was to
make a PHP Standards Group. I imagined it might be useful to have a group
that is not centered on interoperability, and that can put out prototype
standards that don't need to spend as much time going through the FIG
process.
>
> Surely you see the reason for any pushback you're feeling here.
>
Yes, I always see the reason.
>
> I know your response thus far has been that the phrase "PSR" is a generic
> one and that your own "PSRs" aren't popular enough from an SEO perspective
> to compete with the official ones. To the second point, I think most of the
> folks here would argue that it isn't your project's relative popularity
> that is the problem, but rather the precedent that is set when anyone who
> proposes an idea to the PHP-FIG spins up their own organization, creates
> repositories and assigns their own FIG numbers to their own code. This
> would be an immensely confusing mess in very short order, and would leave a
> hundred repositories scattered across GitHub at varying stages of
> completion or stability that are all named "PSR-something".
>
In judging possibilities, you have to deeply consider probabilities or you
will find yourself carried away with absurdities. Nothing has stopped the
scenario you are describing from having happened already, over the passed
many years. Someone could publish as PSR without even having contacted
FIG. But, why does this not occur?
1. Most PHP developers are not interested in making standards.
2. Some subset of PHP developers are interested in following standards, but
they want those standards to be from an established organization, so they
will only follow standards from FIG
3. Consequent to #1 and #2, there is almost no reason to make and no body
that will make PSRs apart from FIG
4. The people who are competent to make standards are normally busy, and
often already part of framework teams
5. Consequent to #5, being part of a framework team, those who would make a
standard and are competent to do so would want to go through FIG so as not
to appear biased towards their framework
I could probably go on, but time is precious.
> Even if developers weren't likely to find those repositories first, the
> idea that they would find them at all, and then associate them with the
> same process that the existing PSRs they're familiar with have gone
> through, is cause for concern.
>
Just to curtail this conversation, I will go ahead and put the header on
all the PSRs of
"This is not a FIG PSR. This PSR does not comply with the rigor applied to
FIG PSRs"
> To your point that the phrase "PSR" is generic, I would be inclined to
> agree if there was any prior art whatsoever that suggested that was the
> case.
>
You see, this is part of where Larry was wrong. I did not say the "PSR"
was generic, I said PHP Standard Recommendation was generic. The
consequence of that, however, is that the long phrase needs to be
abbreviated into PSR to be manageable.
> If you ask people from all around the PHP community what a PSR is, I would
> wager that *all* of the ones who know the term would direct you to one of
> the PHP-FIG standards.
>
Again, I did not argue against this.
> The PHP core team uses a different name for their own proposals, and none
> of the popular frameworks out there (even the ones who don't necessarily
> adhere to the PSR standards) have made their own standards and called them
> "PSRs". This is basically a first, so that's why you're seeing such a
> strong pushback on the concept, because nobody involved wants to set the
> precedent that you can make your own PSRs when submitting ideas to the FIG,
> or in general.
>
Perhaps if I had not spent so much time on this issue responding to emails
that are not technical feedback about the content of the PSRs, and someone
had proposed I instead name them "PPSR" for proposed PSR or prototype PSR,
I might be inclined to spend time renaming them. But at present, I want to
finish PSR 102 and get back to productive things.
> So, really the long and short of it here is it's all in the naming. If you
> can understand where the FIG is coming from in that regard, then we may be
> able to move forward in a productive way.
>
I do understand. I expect the probability that
{
my non-audienced PSRs will spawn an uncontrollable tidal wave of php
developers who suddenly want to make their own PSRs, and that this tidal
wave buries FIG in search engines and makes everyone totally confused about
there being FIG PSRs, and instead think that PSR stands for programming
standards recommendation, which leads to another tidal wave of developers
in all languages making their own PSRs and flooding github to the point
where microsoft begins charging for personal accounts
}
is about 0.
--
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/cd76e3ee-1beb-4fe4-a025-2aa008515f77n%40googlegroups.com.
