PSR-2 PHP constant casing contradicts PSR-1. #47

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants
@sun
Contributor

sun commented Jul 25, 2012

PSR-2 fails the most simple sanity check: Its guide on Boolean/Null constants contradicts PSR-1.

I'm sorry, but I fail to see how this can be "acceptable."

Two possible options:

  1. Make PSR-1 comply (lower-case [class] constants). (ugh)
  2. Fix PSR-2 to be consistent.

@pmjones pmjones closed this Jul 25, 2012

@pmjones

This comment has been minimized.

Show comment
Hide comment
@pmjones

pmjones Jul 25, 2012

Contributor

PSR-1 states that class constants must be upper-case. It says nothing about PHP boolean constants.

Contributor

pmjones commented Jul 25, 2012

PSR-1 states that class constants must be upper-case. It says nothing about PHP boolean constants.

@sun

This comment has been minimized.

Show comment
Hide comment
@sun

sun Jul 25, 2012

Contributor
  • PSR-1 enforces class constants to be in all upper case.
  • PSR-2 enforces Boolean constants to be in all lower case.
Contributor

sun commented Jul 25, 2012

  • PSR-1 enforces class constants to be in all upper case.
  • PSR-2 enforces Boolean constants to be in all lower case.
@milesj

This comment has been minimized.

Show comment
Hide comment
@milesj

milesj Jul 25, 2012

Null, true and false are data types, not constants. So whats the argument here?

milesj commented Jul 25, 2012

Null, true and false are data types, not constants. So whats the argument here?

@sun

This comment has been minimized.

Show comment
Hide comment
@sun

sun Jul 25, 2012

Contributor

Even the PHP manual states:

To specify a boolean literal, use the keywords TRUE or FALSE. Both are case-insensitive.

(not only on that page)

Contributor

sun commented Jul 25, 2012

Even the PHP manual states:

To specify a boolean literal, use the keywords TRUE or FALSE. Both are case-insensitive.

(not only on that page)

@pmjones

This comment has been minimized.

Show comment
Hide comment
@pmjones

pmjones Jul 26, 2012

Contributor

The PSRs are derived from an accumulation of userland code, not from PHP manual examples. I get where you're coming from, but this accepted PSR is not likely to be amended in-place.

Contributor

pmjones commented Jul 26, 2012

The PSRs are derived from an accumulation of userland code, not from PHP manual examples. I get where you're coming from, but this accepted PSR is not likely to be amended in-place.

@sun

This comment has been minimized.

Show comment
Hide comment
@sun

sun Jul 26, 2012

Contributor

I kinda expected some "uphill" battle (definitely feels like that). ;) Thanks for taking the proposal into consideration though. :)

That said:

  1. At least the Drupal community originally built its coding standards upon the PEAR standard (like many others), and wherever it was lacking definitions/clarifications, Drupal pro-actively consulted and coordinated with the php.net manual maintainers, in order to figure out what PHP core thinks about a particular ambiguity in their own documentation. That is, to decrease the confusion for PHP developers (of all skill-levels) and aim for consistency. AFAIK, these efforts led to a range of manual + coding standards adjustments, both on the PHP manual side, as well as Drupal (depending on the outcome of the respective coordination).
  2. Closely tying into the above, and kinda in line with my other PR on acronyms/abbreviations: It is problematic and appears to be wrong to try overrule the coding standard decisions of PHP core (which includes its manual). Any attempt to do so introduces inconsistencies between PHP core code and userland PHP code. At minimum, that conflicts with the goal of PSR adoption.
Contributor

sun commented Jul 26, 2012

I kinda expected some "uphill" battle (definitely feels like that). ;) Thanks for taking the proposal into consideration though. :)

That said:

  1. At least the Drupal community originally built its coding standards upon the PEAR standard (like many others), and wherever it was lacking definitions/clarifications, Drupal pro-actively consulted and coordinated with the php.net manual maintainers, in order to figure out what PHP core thinks about a particular ambiguity in their own documentation. That is, to decrease the confusion for PHP developers (of all skill-levels) and aim for consistency. AFAIK, these efforts led to a range of manual + coding standards adjustments, both on the PHP manual side, as well as Drupal (depending on the outcome of the respective coordination).
  2. Closely tying into the above, and kinda in line with my other PR on acronyms/abbreviations: It is problematic and appears to be wrong to try overrule the coding standard decisions of PHP core (which includes its manual). Any attempt to do so introduces inconsistencies between PHP core code and userland PHP code. At minimum, that conflicts with the goal of PSR adoption.
@pmjones

This comment has been minimized.

Show comment
Hide comment
@pmjones

pmjones Jul 27, 2012

Contributor

Not to be an ass, but at this point, it's not so much "uphill battle" as "the battle is done and we're standing on the memorial site." ;-) The PSR-1 and 2 conversations are long over; the Drupal guys were part of it, along with 20+ other surveyed frameworks/libraries/etc. You can see the survey results as an appendix on PSR-2. You can read more about the process at http://paul-m-jones.com/archives/2420 as well as at http://www.php-fig.org/faq/ .

Regrading acronyms/abbrevs, I suggest starting a conversation on the mailing list.

Contributor

pmjones commented Jul 27, 2012

Not to be an ass, but at this point, it's not so much "uphill battle" as "the battle is done and we're standing on the memorial site." ;-) The PSR-1 and 2 conversations are long over; the Drupal guys were part of it, along with 20+ other surveyed frameworks/libraries/etc. You can see the survey results as an appendix on PSR-2. You can read more about the process at http://paul-m-jones.com/archives/2420 as well as at http://www.php-fig.org/faq/ .

Regrading acronyms/abbrevs, I suggest starting a conversation on the mailing list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment