Codestin Search App

greg0ire · 2020-05-17T09:21:44Z

These changes are a subset of changes done with vendor/bin/psalm --alter --issues=LessSpecificReturnType --allow-backwards-incompatible-changes=false

If you want to see changes I rejected, you can have a look at greg0ire#2

VincentLanglet · 2020-05-17T10:21:45Z

     * Name of the entity class that is cleared, or empty if all are cleared.
     *
-     * @return string|null
+     * @return string


There is a check $this->entityClass === null line 84.

Are you sure this value can't be null ?

Right, I'll revert this, what is wrong here is the property's phpdoc, let's fix it.

VincentLanglet · 2020-05-17T10:32:35Z

     * must override this method and return TRUE.
     *
-     * @return boolean
+     * @return false


I think it's better to keep return boolean to show all possible values.
It can avoid some return type no compatible with parent error message too.

Can it really? false is a boolean, but it is not really a subtype of that. We have both Psalm and Phpstan running on the ORM and neither complained…

https://phpstan.org/r/bde04f1f-84a8-4ad9-888d-91b617d29e24

Ah it's probably that we don't use a strict enough level yet… I will revert this.

VincentLanglet · 2020-05-17T10:33:37Z

     * Filled after {@link dispach()}.
     *
-     * @return \Doctrine\Common\Collections\Collection
+     * @return ArrayCollection


Isn't better to keep the Interface as return type ?

I'm not sure, let see what other people say.

People will code against your advertised return type. The question is: do you need this method to return an ArrayCollection for it to be used properly, or would any Collection be the same, meaning the choice of ArrayCollection is an implementation detail internal to the method itself?

I agree with @kuraobi

I don't need it to be advertised as such, but as a bonus, people can have methods specific to ArrayCollection show up in their auto-completion. Also, their SA tools will not complain if they do use such methods.

It's still narrowing the type, which is a BC break. Please propose it for master if you want that

Narrowing a return type in a concrete class is not a BC break AFAIK, unless you have children classes and no interface to enforce a common contract.

Well there is no interface here, and the class is not final…

>>> interface a{function a():IteratorAggregate;} >>> class b implements a{function a():ArrayObject {}} >>> class c extends b {function a(): IteratorAggregate {}} PHP Fatal error: Declaration of c::a(): IteratorAggregate must be compatible with b::a(): ArrayObject

Yeah so we're all saying the exact same thing 😆

ostrolucky

This is similar to #8144, we should think about complications when upmerging to 3.x, so let's merge it after it's clear what to do there

greg0ire · 2020-05-17T12:57:49Z

This is similar to #8144, we should think about complications when upmerging to 3.x, so let's merge it after it's clear what to do there

Let take this with a grain of salt (lol): the order of magnitude is not really the same (42 files changed vs more than 1000). I can definitely cherry-pick this myself in master afterwards, and I can't say the same about #8144

greg0ire · 2020-05-17T13:18:19Z

I pushed a new version that should make the @psalm-return annotations easier on the eye

ostrolucky · 2020-05-17T13:30:03Z

I appreciate you volunteer to cherry-pick this to master, but I'm not sure it will solve issues when rebasing it. What I worry would happen is that even if you cherry pick this, during rebasing all conflicts would have to be solved again. But of course, I acknowledge this is much smaller PR. I would merge it, but let's see what @guilhermeblanco has to say.

lcobucci

There're plenty of array<array-key... things there that might be relevant for us to alter. Despite that, thanks a lot 👍

lcobucci · 2020-05-19T07:07:39Z

     * @param integer $lifetime
     *
-     * @return \Doctrine\ORM\AbstractQuery This query instance.
+     * @return self This query instance.


Shouldn't we use static instead? Since this is an abstract class and all....

lcobucci · 2020-05-19T07:08:13Z

     * automatically generated for you.
     *
-     * @return array ($key, $hash)
+     * @return string[] ($key, $hash)


Suggested change

* @return string[] ($key, $hash)

* @return array<string, string> ($key, $hash)

lcobucci · 2020-05-19T07:09:46Z

-     * @return array|null
+     * @return mixed[]|null
+     *
+     * @psalm-return array{targetEntity: string, type: mixed, list?: array<array-key, array>, identifier?: array}|null


AFAIK psalm, phpstan, and phpcs understand that if we use it on @return.

Also array<array-key, array> is a bit vague, isn't it?

Also array<array-key, array> is a bit vague, isn't it?

woops, will change that indeed

AFAIK psalm, phpstan, and phpcs understand that if we use it on @return.

I'm doing this out of consideration for PhpStorm users (and also it's what Psalter did naturally). I'm told PhpStorm does not understand this yet, cc @goetas with who I had that debate.

That's probably true... 😭

My general feel on arrays matters are:
1- If array key is ignorable, then use type[] syntax
2- If array key is relevant, then use array<type, type> syntax
3- For maps of maps, repeat the process array<type, array<type, type>>

Anything more complex than 2 requires a comment that describes the return. Also, this hints me that it would be a good candidate for a wrapper object (that encapsulates this logic, make them immutable if needed, only allow pin-point modifications, etc).

Finally, avoid tools specific (aka. non-standardized) markers, such as phpcbf, psalm, phpstan, etc, but rather backed by official standard published publicly, such as xUnit, coverage, etc.

Anything more complex than 2 requires a comment that describes the return

From the original author though, I will have a hard time commenting on that after the fact. I agree that we could require that from contributors.

Also, this hints me that it would be a good candidate for a wrapper object (that encapsulates this logic, make them immutable if needed, only allow pin-point modifications, etc).

I love how this PR makes that kind of code smell more visible

Finally, avoid tools specific (aka. non-standardized) markers, such as phpcbf, psalm, phpstan, etc, but rather backed by official standard published publicly, such as xUnit, coverage, etc.

My hope was to remove the prefixes once Phpstorm has caught up. Also, we can't install a recent enough version of phpcs on this branch to support that, it would require dropping old versions of php I think.

Finally, avoid tools specific (aka. non-standardized) markers, such as phpcbf, psalm, phpstan

My two cents: psalm prefixes are actually compatible with Phpstan and Phan for the most part. Some syntax used is inspired by the unfinished PSR-5 about PHPDoc and it's quite probable that any syntax used in static analysis will make it's way into standards in the end.
Phpstorm is lagging behind because they make the mistake of waiting for standards. It slows adoption, which in turn slows the publication of standards. Adoption by big tools is exactly what we need to help everything move.

I misinterpreted what you meant. However, using @return for advanced notation breaks autocompletion and functionnalities in IDE (I'm sure for PHPStorm and I believe VS Code will have the same issue). This is quite annoying but it will get better when adoption rate of these notations become wider.

lcobucci · 2020-05-19T07:12:11Z

-     * @return array
+     * @return mixed[]
+     *
+     * @psalm-return list<array-key>


Suggested change

* @psalm-return list<array-key>

* @psalm-return list<string>

lcobucci · 2020-05-19T07:12:32Z

+     *                   unique: bool,
+     *                   nullable: bool,
+     *                   precision: int,
+     *                   options?: array,


Array of what?

Of "both"! Ya... if you use ['foo' => true] or ['foo'], it'll lead to the same result and will become FOO on column definition.

Let's use mixed[] here I guess 😅

lcobucci · 2020-05-19T07:15:16Z

+     * @return self This query instance.
     */
-    public function setSQL($sql)
+    public function setSQL($sql) : self


Final classes are just ❤️

lcobucci · 2020-05-19T07:18:15Z

    }

+    /**
+     * @return mixed[]


Wouldn't this be something like \Doctrine\DBAL\Types\Type[]?

lcobucci · 2020-05-19T07:19:59Z

     * @param array $args
     *
-     * @return Base
+     * @return self


lcobucci · 2020-05-19T07:20:50Z

+     * @return ResultSetMapping The result set mapping of the parsed query or
+     *                          NULL if the query is not a SELECT query.


Comment and change don't make sense together

🤔 indeed. The property is private, and from reading its accessor and the setter, it does not look like it could be null, so let's remove that part of the comment.

lcobucci · 2020-05-19T07:22:11Z

+    <rule ref="SlevomatCodingStandard.Classes.UnusedPrivateElements.UnusedMethod">
+        <exclude-pattern>lib/Doctrine/ORM/Mapping/Reflection/ReflectionPropertiesGetter.php</exclude-pattern>
+    </rule>


I'd suggest using // phpcs:ignore SlevomatCodingStandard.Classes.UnusedPrivateElements.UnusedMethod only on the method that's being ignored instead of excluding the entire file.

guilhermeblanco · 2020-05-19T13:46:29Z


    /**
-     * @var string
+     * @var string|null


Please review this, I think the string is always true, not nullable.

clear() can (and should?) be called without an entity name. And from the code it looks like that really happens.

guilhermeblanco · 2020-05-19T13:47:13Z

     *
-     * @return array  An array with all the fields (name => value) of the data row,
-     *                grouped by their component alias.
+     * @return mixed[][] An array with all the fields (name => value) of the


Sharing same thing here as mentioned on https://github.com/doctrine/orm/pull/8150/files#r427314368

Copying same comments shared on Slack:

I’m against using these types of annotations, but rather provide relevant comments on the actual data structure. Also, we should be doing better at describing the data structure (mixed[][] is far from ideal), and rely on array<string, array<string, mixed>> in this scenario. Also, meaningful comments should exist describing the data structure… and finally, complex arrays hierarchies like this one screams the needs of wrapper objects.

guilhermeblanco · 2020-05-19T13:53:39Z

     * @param string $fieldName
     *
-     * @return AssociationBuilder
+     * @return self


static as return type everywhere in this file, since it's inherited by more specialized AssociationBuilders

guilhermeblanco · 2020-05-19T13:56:27Z

     * @param array $mapping The mapping.
     *
-     * @return array The updated mapping.
+     * @return mixed[] The updated mapping.


Oh... now I remember why we started 3.0...
Maybe we should do something on psalm to ignore these return mappings and only enforce on 3.0. The entire 2.X series we are only relying on complex array structures as they were 1- more memory effective and 2- faster than objects.
This is no longer true on PHP 7.

Glad to learn all these mixed[] will go away in 3.x :)

These changes are a subset of changes done with vendor/bin/psalm --alter --issues=LessSpecificReturnType --allow-backwards-incompatible-changes=false

beberlei

What could go wrong? only comments :D

greg0ire mentioned this pull request May 17, 2020

Automated fixes with phpcbf + manual fixes #8144

Merged

greg0ire force-pushed the psalter branch 5 times, most recently from 54e82d6 to f805936 Compare May 17, 2020 10:08

greg0ire mentioned this pull request May 17, 2020

Improve phpdoc of getSingleScalarResult method #8149

Closed

greg0ire requested a review from a team May 17, 2020 10:23

VincentLanglet reviewed May 17, 2020

View reviewed changes

greg0ire force-pushed the psalter branch from f805936 to f4222ca Compare May 17, 2020 10:30

VincentLanglet reviewed May 17, 2020

View reviewed changes

ostrolucky requested changes May 17, 2020

View reviewed changes

Comment thread lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php

Comment thread lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php

Comment thread lib/Doctrine/ORM/Tools/ConvertDoctrine1Schema.php Outdated

greg0ire force-pushed the psalter branch 2 times, most recently from f64b278 to 35c16e7 Compare May 17, 2020 11:42

greg0ire commented May 17, 2020

View reviewed changes

Comment thread lib/Doctrine/ORM/EntityRepository.php Outdated

greg0ire force-pushed the psalter branch from 35c16e7 to 72927ab Compare May 17, 2020 12:00

greg0ire force-pushed the psalter branch from 72927ab to 4bccfb8 Compare May 17, 2020 13:16

greg0ire force-pushed the psalter branch from 4bccfb8 to cf84860 Compare May 17, 2020 13:18

greg0ire force-pushed the psalter branch from cf84860 to 04f54cf Compare May 17, 2020 16:00

greg0ire mentioned this pull request May 17, 2020

Fix issues detected by psalm on 2.7 #7989

Merged

lcobucci reviewed May 19, 2020

View reviewed changes

guilhermeblanco reviewed May 19, 2020

View reviewed changes

greg0ire force-pushed the psalter branch 2 times, most recently from 9433159 to 9f7d9a9 Compare May 20, 2020 06:52

Infer return type information with Psalter

a250769

These changes are a subset of changes done with vendor/bin/psalm --alter --issues=LessSpecificReturnType --allow-backwards-incompatible-changes=false

greg0ire force-pushed the psalter branch from 9f7d9a9 to a250769 Compare May 20, 2020 07:15

beberlei approved these changes Jul 5, 2020

View reviewed changes

beberlei merged commit 6c73a6b into doctrine:2.7 Jul 5, 2020

beberlei added this to the 2.7.4 milestone Jul 5, 2020

orklah mentioned this pull request Jul 5, 2020

add/fix more types (checked by psalm) #8199

Merged

	* @return string[] ($key, $hash)
	* @return array<string, string> ($key, $hash)

		* @return ResultSetMapping The result set mapping of the parsed query or
		* NULL if the query is not a SELECT query.

Conversation

greg0ire commented May 17, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

greg0ire May 17, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ostrolucky left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

greg0ire commented May 17, 2020

Uh oh!

greg0ire commented May 17, 2020

Uh oh!

ostrolucky commented May 17, 2020

Uh oh!

lcobucci left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

greg0ire May 19, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

orklah May 19, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

greg0ire commented May 17, 2020 •

edited

Loading

greg0ire May 17, 2020 •

edited

Loading

greg0ire May 19, 2020 •

edited

Loading

orklah May 19, 2020 •

edited

Loading

guilhermeblanco May 19, 2020 •

edited

Loading