-
-
Notifications
You must be signed in to change notification settings - Fork 564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Phpstan Level 3 #566
Phpstan Level 3 #566
Conversation
private $type; | ||
|
||
/** @var bool */ | ||
private $defaultValueExists = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed this because you can do the same logic by checking the config bucket, but there was and still is a potential bug, here--defaultValue
is public with no setter, so if no default value is passed at construction time but is set after the fact, then defaultValueExists
will still return false
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically GQL types are supposed to be immutable once created. Unfortunately, PHP doesn't provide any means for read-only properties. Doing getters for every single data point is tedious; __isset
and __get
are readability and static checking nightmares (although definitely useful for backward compatibility)
I prefer assuming that people are sane enough not to shoot themselves in the foot. But when they want to - nothing will stop them. We even have a dedicated tool for this called Reflection
%)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't intend to fight this battle in this PR, but there are ways to have read-only properties. For example:
class FieldArgument {
private $_defaultValue;
public function __get($name) {
switch($name) {
case 'defaultValue`:
return $_defaultValue;
}
}
}
There are, of course, drawbacks to this kind of thing (eg. no intellisense), and I'm not seriously recommending it at this point.
/** | ||
* @see it('rejects an empty Object field type') | ||
*/ | ||
public function testRejectsAnEmptyObjectFieldType() : void |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No longer needed! PHP itself will throw an error if type is not provided and not Type
.
*/ | ||
public function testRejectsANonTypeValueAsAnObjectFieldType() | ||
{ | ||
$schema = $this->schemaWithObjectFieldOfType($this->Number); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No longer necessary. PHP will throw.
*/ | ||
public function testRejectsAnEmptyInterfaceFieldType() : void | ||
{ | ||
$schema = $this->schemaWithInterfaceFieldOfType(null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not needed.
'arg1' => ['name' => 'arg1'], | ||
'arg1' => [ | ||
'name' => 'arg1', | ||
'type' => Type::string() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This missing type property was caught by PHP's natural checking.
🤔 wow, #TIL When I look through the PR, 99% (just a feeling) of what I saw regarding the type changes (ecept the multiline array) looks great. Any reason this would need to be part of this "waiting" PR? Looks to me the majority of the changes (i.e. "no brainer changes") could be made independently already, no? |
That's a good point. I'll see if I can separate that stuff out tomorrow morning... |
Btw, its there a "standard" for this? Does any IDE out there support this? Quickly tried PhpStorm, doesn't seem so. Neither the referenced PR nor the issue seem to reference the origin of this format. Thanks |
I don't know. The original PR that brought it into phpstan/phpdoc-parser didn't mention anything; best I could find is this issue, which mentions a similar feature in psalm's docblocks. Digging further, I found this, which describes the feature as a "special format for arrays". The PHPDoc proposed PSR-5 standard doesn't have this feature. Phan also has something similar, though I didn't bother digging down to find its source (interestingly, phan seems to credit the idea to phpdoc). I guess we'll have to consider this sort of a graphql/phan/psalm-only feature. |
I think it was first introduced in psalm https://psalm.dev/docs/annotating_code/type_syntax/array_types/#object-like-arrays. PHPStorm is kinda slow in implementing this, I think I even created ticket for them. But eg. ticket for generic collection support is there in top voted tickets for ages already. |
Interesting. When PSR-12 was about to be ratified, I couldn't change my shirt faster than they started implementing it. Guess having something "official" can boost this. Sorry for OT and @shmax thanks for digging deeper, obviously I did a bad job at researching 👍 |
Removed the array shape stuff for now. Will open a new PR if this gets merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gj!
@simPod thanks very much for the thorough review! I think I addressed all your comments. Ready for the next round... |
Sorry for all the extra commits in this PR--I had to keep fighting with it to make Scrutinizer happy. By the way, are you guys still all-in on Scrutinizer? Trying to keep its black-box code analyzer happy (its got plenty of its own bugs) is a serious pain. We could probably configure it to use PHPStan instead of its own checker; I'm willing to investigate the idea if anyone is interested... |
Co-Authored-By: Šimon Podlipský <simon@podlipsky.net>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
If @vladar thinks it's good to go, I'd squash commits before merge. |
Sure, happy to squash, but doesn't Github have the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is trully a great job! I've left a bunch of comments but we'll definitely merge this as soon as remaining questions are resolved.
Merged! Thanks for this exceptionally useful PR! |
Woot! Thanks for merging, and thanks all for reviewing! |
PHPStan Level 3!
This is already a really tight, beautifully put together code base, so there wasn't that much to do, but there were a few points of interest:
isInputType
,isOutputType
, andisCompositeType