Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Clarify abbreviations and acronyms in PSR-1 method names. #48

wants to merge 1 commit into


None yet
2 participants

sun commented Jul 25, 2012

Warning: Given the wide-spread adoption of strict camelCase in user-space PHP code, I realize and naturally expect some push-back here.

However. PHP core is crystal clear with regard to acronyms and abbreviations, at least in its more "recent" extensions.

Thus, if PSR-* has any goal of consistency, then it should definitely follow the lead of the very language interpreter it is trying to form standards for. Otherwise, it would intentionally be inconsistent with class methods provided by PHP core.

Two possible options:

  1. Diverge from PHP core and "do what others do."

    Essentially introducing and enforcing a huge inconsistency between user space method names and PHP core method names.

  2. Do what PHP core does. Native consistency.

Background: http://drupal.org/node/1627350

@pmjones pmjones closed this Jul 26, 2012


pmjones commented Jul 26, 2012

PSR-1 is not likely to be amended in-place. However, I think your patch is part of a larger issue: that of how to name methods, and of a common vocabulary for methods. This is probably best addressed in a followup PSR, not as an amendment. I suggest raising this in a new thread on the mailing list.


sun commented Jul 26, 2012

mmm... the readme states:

  • fork this repo, create a branch, checkout that branch, add the PSR in proposed/, push the branch to Github, and send a pull request; OR,
  • create a ticket to start a discussion on Github; OR,
  • start a conversation on the mailing list.

(emphasis+casing mine)

The first option is exactly what this is — except that the chapter about camel-cased method names already exists in accepted/ - but it's lacking details about acronyms and abbreviations.

In turn, that complicates the adoption of PSR, since individual opinions and interpretations vastly differ. My goal is to increase the adoption level of PSR, by providing clarifications — comprehensible clarifications.

I'm not familiar with the php-fig mailing list. Could we just send a pointer to this PR to the list? At least, that seems favorable, since there is a very concrete change proposal attached to this PR.


pmjones commented Jul 27, 2012

The readme bit on forking the repo is for creating new PSRs, not amending old ones.


pmjones commented Jul 27, 2012

And, incidentally, the link to the mailing list is very last item in the list you quote above from the readme. Please feel free to join the list and start a conversation there.

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