PSR adoption

[nickl-]

@Respect I am opening this issue again here since discussions that took place at Respect/Validation#106 was on a PR that can't be re-opened and we need to come to a conclusion on this matter.

Recap on what's been said

I am not against any of the proposals (which does not mean I agree with them), but I do not intend to spend efforts on moving our code base towards compatibility with both PSR. But if someone like @henriquemoody do something towards it, I will no oppose myself

@augustohp

I wanna use all PSR, but if we get a consensus of to not use, that's Ok.

@henriquemoody

I know PSR-2 is optional and I believe we should adopt it to show commitment to PHP standards, even though we disagree.

@alganet

Why the blind compliance it is not better because they say so. This is how we've been coding in any case and it will make the updates easier.

@nickl-

Our Principles

• Keep it small and simple.
• Clean interfaces. Easy to learn, a pleasure to use.
• Work together with PHP. Don't try to change it, don't try to hide it.
• ...

  Our current standards

We have our Coding-Standards including a sample code example so it's not that we do not have something to work with and desperately in need of some guidelines.

"Arguments over style are pointless. There should be a style guide, and you should follow it"

- Rebecca Murphey

Our sample did actually end up being 1 of the 22 surveyed, did anyone know that? Even though we only had an, 0.8th of a vote I still say kudos Respect! If they just dropped us a line in the interim we could've given them a full example with all the information required for their evaluation. But this is the point...

What are the PSRs for

What is this whole rigmarole all about, lets hear what Paul Jones wrote in Jun from PHP-FIG said just after the initial PSR Coding style release:

the primary audience for the recommendations is the group itself. If others in the wider PHP community want to adopt the recommendations, I think that’s a positive outcome, but it’s certainly not mandatory in any way.

We’re not trying to make anyone do anything. Hell, not even all of the member projects subscribe to all of the standards recommendations. What we’re trying to do is find commonalities between the projects so that we (the members) can all eventually share similar practices and techniques.

So there you have it from the horses mouth, even though they "considered" our practices, purely because we had an example available, we actually have nothing to do with FIG, PSRs or what they may or may not stand for. I know we previously discussed the possibility of applying for membership and perhaps we need to step up and represent. Bottom line, if we want to align ourselves with FIG we need a voting member on the ranks.

Respect

We are not having it as bad as others, recently PSR-3 Logger Interface was finalized in our absense but this was also news to log4php who was not considered, approached or informed about their intended new list of Log levels EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG, which are strings and not bitmask values like we are used to, by the way. In comparison the log4php LogLevel class defines OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE, ALL which is already closer to what we are used to from the PHP Error Constants and they are numbers as you can see.

Not consulting the current experts in the field, proposing new practices without any technical considerations it is no wonder; the request to have PSR-0 included in PHP core saw resistance from the greater PHP community and is considered broken, PSR-3 shows no Respect for PHP and without bitmasks is also broken! The only thing we all seem to agree on is PSR-1 and if we can't even have consensus on "standards" or at least agree that it works, then the whole concept is flawed.

Conclusions

Summing it up: I disagree with some standards, but I agree to follow standards. Specially 'cause this a standard we could possibly change in the future. I'm +1 for PSR-2 in its current state and also +1 for proposing a change to it.

@alganet

I hardly believe that any changes will be made into PSR-1 and,

@augustohp

proposing this change I am afraid will be beating a dead horse

@nickl-

I'm +1 for all PSR in its current state and also +1 for proposing a change to it.

@henriquemoody

The facts are:

• We have firstly our own principles to uphold
• PSRs are NOT STANDARDS
• PSRs are for FIG members and for their goals and principles ONLY

My objections with parts of PSR-2 are those aspects that go against our principals; it results in less concise code, which are messy and no pleasure to work with and tries to change PHP. I agree with @alganet we abide by standards whether we like them or not, but the whole thing with standards are that they have consensus, are thoroughly thought out, works and these are not standards. The question is, for what we might gain by adopting these, is it worth giving up everything we stand for?

To FIG or not to FIG

If we do want to be a part of the movement and we think we can change their minds and modify the guidelines, it starts with applying for membership and having a voting member involved. Even though I still feel the same way, that we are small and better served utilizing the available resources for what we aim to accomplish. I will not stand in the way. If someone else wants the extra responsibility you will have my support. If however you are unable to sway them towards reason and common sense, my continued resistance to blindly adopt anything considered broken without sufficient modification to rectify the faults, can be expected.

In the meantime can we please agree to reallign with our principles and get back to using our code styles now?

[nickl-]

@Respect Request for PSR-2 change at php-fig/fig-standards#101

Excuse the high english I thought it best to be a bit formal to help us get the change

[nickl-]

Done with that, nope no success. Basically we can forget about changing anything it just aint going to happen. If they were members only it would seem they are heading towards even more so members only.

In response to so many request to change the will be realeasing a response to PSR-2 apparently which goes something like.

• You don't have to use PSR-2, we're not even using it but please do.
• You can use PSR-2 but you don't have to but please do.
• PSR-2 is for members only and you don't have to use it, but please do.
• You can use it and change anything you like as you like, this won't be confusing at all we promise.
• You can use your own code conventions and get the PHP community to adopt it, see we're doing it.

We'll wait and see...

[henriquemoody]

Hey @Respect/troubleshooters, it's been a while since this issue was opened, and this is probably a tl; dr issue. Any way, after almost 2 years of PSR adoption do you really think we should keep or own standards or use the FIG ones?

I'm in favor of FIG ones

[williamespindola]

Use FIG.

[alganet]

Let's FIG!