On Thu, Jun 6, 2019 at 4:16 AM Alessandro Lai <alessandro.la...@gmail.com> wrote:
> Hello everyone, > I would like to push forward a proposal that is bugging me for so long. > Today I read this comment on our GitHub: > https://github.com/php-fig/fig-standards/pull/1171#issuecomment-499382349 > > Larry correctly shot down the last in a long list of small PRs that our > approved PSRs had received in the past. This is because the PSRs, as > standards, should be immutable, and they cannot be changed meaningfully, > apart from small erratas. > > I would like to change that. > > This is a topic that many times surfaced in our chats, but we never tried > to solve it. The release schedule of the language is a lot more tight and > fast compared to the past, and we need to keep up the pace, to avoid that > our PSRs become obsolete in a matter of years. > > My proposal is simple but limited; I didn't work on a full text change of > our bylaws, but before I delve in the technicalities I would like to try > and explain my idea succinctly, to see if I have some consensus about it. > > This is the summary of my proposal: > - PSRs packages can receive new major releases > - new majors should be used just to improve the code, so that it can use > new language features (types, return type, void, \Throwable...) > - the new major should never break the spec > - implementors should be able to easily support all majors of the package > (AKA "psr/*": "^1.0|^2.0"); even more, it should be recommended > - if possible, the additions to the spec should just be added to > implement in code something from the spec that before wasn't expressible > before (like exceptions interfaces extending `\Throwable`) > - a changelog should be appended to the PSR to reflect the changes in the > new version > - the process to make this happen should be: > -- PR to the PSR > -- demonstrate straightforward cross-compat between version > -- editor approval, calls a CC vote > -- CC vote with 2/3 majority > > What do you think? Do you think this is doable? > I really like this idea! The one part I don't think is possible is the line "implementors should be able to easily support all majors of the package ... it should be recommended." Why? Because some language changes are not compatible with previous versions. As an example, if we have the following in the original spec: interface Car { /** * @param string $brand * @return self */ public function withBrand($brand); } and v2 then updates to take advantage of scalar type hints and return type hints: interface Car { public function withBrand(string $brand) : self; } then an implementation MUST choose one version or the other. Why? - If it targets the v1 spec, it will be incorrect for v2, as the typehints are missing entirely. - If it adds typehints to follow v2, it's invalid for usage with v1, because v1 defined no typehints. (This is not a problem if only an RTH is added; however, as soon as any arguments have typehints, it is.) (See https://3v4l.org/JbEJI for an example; you can comment out one or the other implementation to see the errors each produces.) Consumers generally won't need to care much, as the _usage_ will be identical. They can safely pin to multiple versions of the PSR package. However, the packages _providing the implementations_ will have to do some nasty dynamic polyfill stuff to make it work, and it will only get harder the more versions they need to support. I'd argue implementors should bump major versions to support new versions of the PSR package. -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him -- 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/CAJp_myV0%2B-cEKFyNdTZxZX-2rOVLpTvP0pvU5F5iJO4m_aYDkg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
