[5.0] PSR-2 AND PSR-5 #6941

Closed
wants to merge 2 commits into
from

Projects

None yet
@GrahamCampbell
Member

No description provided.

@Anahkiasen
Contributor

๐Ÿ‘

@GrahamCampbell GrahamCampbell changed the title from [5.0] [WIP] PSR-2 AND PSR-5 to [5.0] PSR-2 AND PSR-5 Jan 7, 2015
@RomainLanz
Contributor

๐Ÿ‘

What do you think about keep the namespace on the same line that the <?php tag?

@GrahamCampbell
Member

PSR-2 doesn't allow it unfortunately.

@GrahamCampbell
Member

It says it must be on a new line, and common convention is to leave another line between that opening tag and the namespace, so I did that.

@RomainLanz
Contributor

I never see that is not possible for the namespace. The only one rule for the position is : When present, there MUST be one blank line after the namespace declaration.

When present, there MUST be one blank line after the namespace declaration.

When present, all use declarations MUST go after the namespace declaration.

There MUST be one use keyword per declaration.

There MUST be one blank line after the use block.
@Anahkiasen
Contributor

It's not in PSR2 but to be fair apart from in Laravel I've never seen it on the same line and since the point here is to go towards unification with other frameworks, I'd say putting it on a new line would be best no?

@GrahamCampbell
Member

Agreed.

@JoostK
Contributor
JoostK commented Jan 7, 2015

Why does PSR-2 have to be so ugly ๐Ÿ˜ข

@GrahamCampbell
Member

PSR-2 is pretty :) I've got used to it.

@RomainLanz
Contributor

PSR-2 is not ugly IMO.

Ok, no problem for the namespace, I just think that it's better to have it on the same line.

@hannesvdvreken
Contributor

๐Ÿ‘

@KennedyTedesco
Contributor

Beautiful! ๐Ÿ‘

@shin1x1
shin1x1 commented Jan 8, 2015

๐Ÿ‘

@tomschlick
Contributor

๐Ÿ‘

@ibrasho ibrasho commented on the diff Jan 8, 2015
src/Illuminate/Auth/DatabaseUserProvider.php
+ $user = $this->conn->table($this->table)->find($identifier);
+
+ return $this->getGenericUser($user);
+ }
+
+ /**
+ * Retrieve a user by by their unique identifier and "remember me" token.
+ *
+ * @param mixed $identifier
+ * @param string $token
+ *
+ * @return \Illuminate\Contracts\Auth\Authenticatable|null
+ */
+ public function retrieveByToken($identifier, $token)
+ {
+ $user = $this->conn->table($this->table)
->where('id', $identifier)
->where('remember_token', $token)
->first();
@ibrasho
ibrasho Jan 8, 2015 Contributor

Alignment?

@GrahamCampbell
GrahamCampbell Jan 8, 2015 Member

I have no automated way to fix such cases. Also, I don't think PSR-2 says anything about this.

@ibrasho
ibrasho Jan 8, 2015 Contributor

I know, but I think we want to keep the Laravel-ish feel. :-)

@ibrasho ibrasho commented on the diff Jan 8, 2015
src/Illuminate/Auth/DatabaseUserProvider.php
- {
- $this->conn->table($this->table)
+ return $this->getGenericUser($user);
+ }
+
+ /**
+ * Update the "remember me" token for the given user in storage.
+ *
+ * @param \Illuminate\Contracts\Auth\Authenticatable $user
+ * @param string $token
+ *
+ * @return void
+ */
+ public function updateRememberToken(UserContract $user, $token)
+ {
+ $this->conn->table($this->table)
@ibrasho
ibrasho Jan 8, 2015 Contributor

Alignment?

@GrahamCampbell
GrahamCampbell Jan 8, 2015 Member

the alignment is correct here

@ibrasho ibrasho commented on the diff Jan 8, 2015
src/Illuminate/Auth/Guard.php
+ if (! $this->once($this->getBasicCredentials($this->getRequest(), $field))) {
+ return $this->getBasicResponse();
+ }
+ }
+
+ /**
+ * Attempt to authenticate using basic authentication.
+ *
+ * @param \Symfony\Component\HttpFoundation\Request $request
+ * @param string $field
+ *
+ * @return bool
+ */
+ protected function attemptBasic(Request $request, $field)
+ {
+ if (! $request->getUser()) {
@ibrasho
ibrasho Jan 8, 2015 Contributor

Should not this be if ( ! $request->getUser()) {?

@RomainLanz
RomainLanz Jan 8, 2015 Contributor

The exclamation point is not reglemented on PSR-2, I think it's more readable to keep a space before and after it too.

What do you think @GrahamCampbell ?

@crynobone
crynobone Jan 8, 2015 Contributor

It's part of PSR-2

Opening parentheses for control structures MUST NOT have a space after them, and closing parentheses for control structures MUST NOT have a space before.

@crynobone
crynobone Jan 8, 2015 Contributor
if ( $foo ) { // wrong
if ($foo) { // right
if (! $foo) { // is not wrong :P
@GrahamCampbell
GrahamCampbell Jan 8, 2015 Member

Yeh, this is fine as it is.

@gaomd
gaomd Jan 9, 2015 Contributor

if ( ! $foo) { // seems more readable

@gregrobson
gregrobson Feb 4, 2015

Personally I have found that removing the negation from the if statement is the best solution as it improves readability.

if (! $request->getUser()) {
// vs
if ($request->noUserSpecified()) {

I haven't used the above method in my own code, but hopefully it demonstrates the idea. as another example it's far easier to say is empty than does not have more than 0 items

@anhskohbo
Contributor

๐Ÿ‘

@taylorotwell
Member

Rebase? :)

@GrahamCampbell
Member

Will do when I find a min.

@hannesvdvreken
Contributor

Cool! ๐Ÿ‘

@jwpage
jwpage commented Jan 9, 2015

Just curious, will there be an accompanying PR for laravel/laravel so that the code there is PSR-2+5 as well, or is this only going to be a standard for laravel/framework?

@xiaobeicn

๐Ÿ‘

@alioygur
Contributor
alioygur commented Jan 9, 2015

๐Ÿ‘

@alioygur
Contributor
alioygur commented Jan 9, 2015

@GrahamCampbell it should be on laravel/laravel

@GrahamCampbell
Member

Yeh, I will do it there too. I'll do it once Taylor's totally happy with the default app.

@GrahamCampbell
Member

And indeed on the other laravel repos.

@GrahamCampbell
Member

NB, I'll be rebasing this once 4.2.17 is tagged, and merged with the master branch.

@zombopanda

๐Ÿ‘

@GrahamCampbell
Member

I'll resend this at a later point when we're truly ready to do this. The merging of this pull will mean that Laravel 4.2 is no-longer maintained for anything but more important bug fixes, so we'll be doing this close to the 5.0.0 release.

@GrahamCampbell GrahamCampbell deleted the GrahamForks:5.0-cs branch Jan 19, 2015
@JosephSilber
Contributor

@GrahamCampbell at that cutoff point, shouldn't we also convert all arrays to the short syntax?

@ibrasho
Contributor
ibrasho commented Jan 20, 2015

^ I agree.

@GrahamCampbell
Member

@GrahamCampbell at that cutoff point, shouldn't we also convert all arrays to the short syntax?

I already did that as part of this change, and yeh, I will be doing that in the replacement too.

@GrahamCampbell
Member

NB, only on 5.0.

@HipsterJazzbo
Contributor

Is this going to happen for release? Can't stand the suspense!

@overtrue
Contributor
overtrue commented Feb 4, 2015

PSR-2 is pretty ๐Ÿ‘

@daids
daids commented Feb 4, 2015

๐Ÿ‘

@GrahamCampbell
Member

This is not ever going to happen, sorry.

@overtrue
Contributor
overtrue commented Feb 4, 2015

@GrahamCampbell What a sad ending... ๐Ÿ˜ข

@Anahkiasen
Contributor

@GrahamCampbell
Member

I'm a bit gutted too. Taylor does have a point that this whole cs thing is a total waste of time.

The big issue for me is not that laravel/framework's code isn't PSR-2, but all the generated files arn;t PSR-2, which means I have to change them every time. :(

@Anahkiasen
Contributor

Taylor does have a point that this whole cs thing is a total waste of time

I don't think that's a good argument, I'd rather have it be a waste of time once and then being able to let a tool fix them every time

@MaartenStaa

I have to agree with Maxime. It's quite a bit of work up front, but once you're there, there's a lot of nice tools for enforcing PSR-2.

It personally took me a while to get used to the standard, but now I think it's a prettier CS than what Laravel uses. Plus, since so many packages/frameworks use it, that's really a big plus IMO.

@crynobone
Contributor

I'm a bit gutted too. Taylor does have a point that this whole cs thing is a total waste of time.

It would be useful if Laravel 4.2 still support minor bugfix (instead of just security fix). Expecting everyone to jump to 5 straight away when they have production code when what not available right now in 4.2 is some minor bugs IMHO is not acceptable. The idea right now is Laravel 5 going to be available today (update now as Laravel 4 is EOL unless there some security issue).

p/s: I am under the assumption that 4 become security only due to moving to PSR-2.

@barryvdh
Contributor
barryvdh commented Feb 4, 2015

It's a total waste of time having to explain the differences of the Laravel CS to everyone, commenting on PR's, not having to validate with proper tools, no default settings in most IDE's etc.
Regular contributors know the difference, but it's annoying to keep on switching. External contributors usually just assume PSR-2..

If Taylor doesn't care, but a lot of contributors do, why not listen to them?

@GrahamCampbell
Member

I think the point he's making is it doesn't really matter if the cs of contributions is incorrect.

He's made up his mind already anyway. I want everything to go PSR-2, but he doesn't.

@barryvdh
Contributor
barryvdh commented Feb 4, 2015

I think the point he's making is it doesn't really matter if the cs of contributions is incorrect.

Wait, are you saying we can just submit PR's in any CS we want? So just submitting stuff in PSR-2 is okay too? ;)

@GrahamCampbell
Member

No, it's not ok. Hmmm. This is a mess if you ask me. :/

@Garbee
Contributor
Garbee commented Feb 4, 2015

imo, if a PR is sent with improper CS it would be just as quick to pull the PR in locally, fix the CS and push it up then it would be commenting on every little damn thing. However, that would end up being a huge time resource with all the little issues found then it would be to just go PSR-2 and let tools handle it.

Everyone is correct, this does a major hurt exactly once, aside from needing to backport fixes since it ends up making more work to do that between 5.x and 4.x. But once that is done everything is more seamless for the majority of developers using the platform.

Moving to PSR-2 could also lead to more contributions back since it is less friction to make sure you are coding to the Laravel standard instead of PSR-2 (or any other code style that has a wide array of tooling available.)

However, it looks like 5.0 has gone stable within the past few hours with all the site updates and all. So this shipped has sailed for this major. Maybe with 6.0...

@Anahkiasen
Contributor

Honestly considering how different the L5 and L4 codebases are now I don't think CS are would even be the main reasons backports are hard

@GrahamCampbell
Member

If Taylor did change, he'd only do it on the framework repo, and not the other repos, which I also think is very strange. It's to late now anyway.

@GrahamCampbell GrahamCampbell locked and limited conversation to collaborators Feb 4, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.