Refactor InitializerExprTypeResolver#4861
Conversation
|
This pull request has been marked as ready for review. |
VincentLanglet
left a comment
There was a problem hiding this comment.
I was wondering if this simplification was interesting enough or if we should/could include the whole if ($leftTypesCount > 0 ...) given the fact the only changed line were
$resultType = $this->getTypeFromValue($leftTypeInner->getValue() | $rightTypeInner->getValue());
$resultType = $this->getTypeFromValue($leftTypeInner->getValue() & $rightTypeInner->getValue());
$resultType = $this->getTypeFromValue($leftTypeInner->getValue() ^ $rightTypeInner->getValue());
and could be resolve with a callback ; WDYT ?
e4d27f8 to
a6f947b
Compare
good idea - did it like that now. my initial idea was to turn the pattern into a thank you |
| * | ||
| * @return self::IS_UNKNOWN|self::IS_SCALAR_TYPE|Type | ||
| */ | ||
| private function getFiniteOrConstantScalarTypes(Type $leftType, Type $rightType, callable $operationCallable): int|Type |
There was a problem hiding this comment.
The method might be easier to read with early return ?
if ($leftTypesCount === 0 || $rightTypesCount === 0) {
return self::IS_UNKNOWN;
}
...
if ($generalize) {
return self::IS_SCALAR_TYPE;
}
...
return TypeCombinator::union(...$resultTypes);
```
I also wonder if a Type|bool isn't enough (and avoid introducing two constant). True when it need to be generalized.
Another solution could be including the generalize call inside this method and returning `[$leftType, $rightType, $result]` but I'm not sure it should be preferred.
There was a problem hiding this comment.
The method might be easier to read with early return ?
done.
I also wonder if a Type|bool isn't enough (and avoid introducing two constant).
I had it like that before I introduced constants. was not happy with the client-side code of this method as it was pretty unreadable.
After looking again at #4435 I think this minor simplification makes sense