[PSR-12] Enforce short type keywords

[Alexander Makarov]

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 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.

[Woody Gilk]

I like this suggestion. One Right Way is always better than ambiguity.
--
Woody Gilk
http://about.me/shadowhand

> --
> 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/78e98bf5-7735-4fbf-976a-e49e60e3de2d%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Marc Alexander]

First of, I don't see this conflicting with PSR-5. If it is, feel free to link me to the section that this would conflict with. It does actually seem to recognize the proposed type keywords.

As this is also in line with other programming languages, I'd also be in favor of enforcing these type keywords.

[Larry Garfield]

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

[Alexander Makarov]

PSR-5 scope is phpDoc exclusively. It cannot affect types used for typecasting.

[Michael Cullum]

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)

--

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.

[Alexander Makarov]

So would it be OK if we won't touch documentation i.e. remove "in both code and documentation blocks"?

[Korvin Szanto]

I think that's the way to go. Change it from "in both code and documentation blocks i.e." to "in code i.e."

Thanks,

Korvin

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/105b283c-d5d7-4dba-a3e6-582efe393226%40googlegroups.com.

[Michael Cullum]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/105b283c-d5d7-4dba-a3e6-582efe393226%40googlegroups.com.

[Alexander Makarov]

https://github.com/php-fig/fig-standards/pull/791