On 08/01/2016 01:32 AM, Andrew Carter wrote:
Some projects still don't use PSR-2 because of the hell involved in changing
style guide mid project when you have hundreds of pull requests. PSR-2 didn't
have the option of being prescriptive.
Additionally, the "lowest common denominator only" approach of PSR-2 led
to inconsistencies that still hinder its adoption. (The confusing and
inconsistent braces placement is *the* number 1 reason why Drupal still
refuses to adopt PSR-2, even moreso than the massive impact on the
codebase and community that such a change would entail.) Simply rubber
stamping a plurality survey does not lead to a consistent and coherent
spec, which is what we should be striving to achieve.
The job of the FIG is to solve problems by working together?
These projects are the community, so if they all work together creating one now
- there's the best chance of acceptance. The more code written with custom
style guides - the less likely this standard will achieve acceptance amongst
the bigger projects.
All projects here will need a PHP 7 style guide. Just make one together now
rather than all making different ones.
I've got nothing else to add so self throttling. Maybe this is the sort of
thing voting members need to be surveyed on (prescriptive or descriptive).
Also quoting from Chris Tankersley:
> Which is the intent of the FIG? To provide an after-the-fact decision
on how things should work, like the RFC process, or provide details on
how things should work _before_ there is widespread adoption, more akin
to the ISO process?
In practice, a balance between the two. That is informally the case
now, and FIG 3's mission statement makes that explicit. We should not
be inventing things entirely from whole cloth, but that doesn't mean we
are bound exclusively to "what's been done already we can rubber stamp",
either.
PSR-0 was similar to the PEAR convention, but as no one was using
namespaces yet it was still forward-looking, based on experience.
PSR-3 was closely based on Monolog, but also pulled in a tokenizing
system inspired by Drupal, but using a syntax that was more Twig-esque
than either system.
PSR-4 was based on a feature request, but no one was using "truncated"
paths yet at that point. It was new, innovative, and controversial, but
the right call.
PSR-6 was developed essentially in parallel with Stash.
PSR-7 was naturally inspired by both HttpFoundation and Zend Framework's
Request library, but the use of a mostly-immutable design was fairly new
and neither major HTTP library at the time was already doing that. It
was still a good call, however, despite being "innovative".
We absolutely should gather data on what projects are already doing
already (for PSR-12 or for anything else), but it is grossly negligent
to say that we must be enslaved to the result. Producing a good spec is
more important than producing a legacy-centric spec. Historically,
that's almost always been our approach, and should remain so.
And now we've repeated in this thread the same conversation we've had
about PSR-12 every time it's come up, to the same result.
--Larry Garfield
--
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 post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/7665a689-c092-ab2e-4e33-122643f3fa7c%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
