My main issue with this change is that it dictates how it should be used in documentation (essentially doc blocks and comments), and presently nothing (I think) in PSR-2 or PSR-12 dictates how comments or docs should be done as well as code. I'd therefore say this is out of scope.
Furthermore, whilst neither of these two issues are enough to warrant removal on their own [in my opinion], I'd add it introduces a BC break on PSR-2 which is relatively un-necessary nor hugely helpful and the link to it being added due to a PHP 7 feature is rather tenuous (although no more so than that relating to operators, hence I say this is not reason enough on its own). Many thanks, Michael Cullum (Not speaking as Secretary but as Former PSR-12 Editor inline with declared conflicts of interest) On 2 Aug 2016 9:10 a.m., "'Alexander Makarov' via PHP Framework Interoperability Group" <[email protected]> wrote: > PSR-5 scope is phpDoc exclusively. It cannot affect types used for > typecasting. > > On Monday, August 1, 2016 at 6:32:45 PM UTC+3, Larry Garfield wrote: >> >> On 07/31/2016 02:03 PM, 'Alexander Makarov' via PHP Framework >> Interoperability Group wrote: >> >> For the PSR-12 coding standard I've made a change that forces using short >> form of type keywords i.e. bool instead of boolean, int instead of integer >> etc.: >> >> >> https://github.com/php-fig/fig-standards/commit/a77993bdf52eb6d5cb9ca37dba3af4df9e3b909c >> >> As Michael Cullum pointed out, I was too fast and it should be discussed. >> I need your answers for the following questions: >> >> 1. If this additional rule makes sense? >> 2. What possible drawbacks are there? >> >> *Why was the change made* >> >> PHP 7.0 introduced scalar types declaration >> <http://php.net/manual/en/functions.arguments.php#functions.arguments.type-declaration> >> which does not support long type aliases. Therefore it makes sense to >> enforce primary short type forms to be used to have uniform syntax and >> prevent possible confusion. >> >> *Counter-agruments from Michael* >> >> This could conflict with other PSRs like PSR-5 and seems out of scope of >>> this PSR to be honest. >> >> >> I fully agree with the policy. With PHP 7 using only short-versions for >> types it makes sense for everything else to follow that as well. >> >> However, I'm sympathetic to the scope question. It does seem more like >> PSR-5's responsibility. PSR-5 isnt' finalized (and is currently fallow), >> so it's not binding on anything. >> >> I guess I could go either way here, although unless PSR-12 considers >> coding style within docblocks generally to be in scope (I don't think it >> does?) I'd probably agree with Michael and remove it. Whenever PSR-5 gets >> reactivated that change should be made there instead. >> >> --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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/e0e682fe-10b4-4ca5-893c-28f103b14409%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/e0e682fe-10b4-4ca5-893c-28f103b14409%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAqcDMjb1J2%3D65dr2-c0OB9XcD9OjyKiqOcXnh9ZfiTJo46jLQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
