https://github.com/php-fig/fig-standards/pull/791
On Tuesday, August 2, 2016 at 8:40:41 PM UTC+3, Michael Cullum wrote: > > That would certainly be more in scope yes and I'd no longer have any > objections but I wouldn't be in favour either; I'd say I'd then be neutral > on the change. > > -- > Michael C > > On 2 August 2016 at 14:24, 'Alexander Makarov' via PHP Framework > Interoperability Group <php...@googlegroups.com <javascript:>> wrote: > >> So would it be OK if we won't touch documentation i.e. remove "in both >> code and documentation blocks"? >> >> On Tuesday, August 2, 2016 at 1:28:07 PM UTC+3, Michael Cullum wrote: >>> >>> 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" <php...@googlegroups.com> 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 php-fig+u...@googlegroups.com. >>>> To post to this group, send email to php...@googlegroups.com. >>>> 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 php-fig+u...@googlegroups.com <javascript:>. >> To post to this group, send email to php...@googlegroups.com >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/105b283c-d5d7-4dba-a3e6-582efe393226%40googlegroups.com >> >> <https://groups.google.com/d/msgid/php-fig/105b283c-d5d7-4dba-a3e6-582efe393226%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 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/c640107e-d7c8-484e-8f77-2fb280d52c9e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
