Closed GameplayJDK closed 3 years ago
Hello everyone,
while working on #917 i noticed a missing assert() in the method getParameterType() of the ProxyGenerator.
assert()
getParameterType()
ProxyGenerator
The ReflectionParameter::getDeclaringFunction() method returns a ReflectionFunctionAbstract, the type hint of ProxyGenerator::formatType(...) is ReflectionMethod, one of two possible implementations, the other is ReflectionFunction.
ReflectionParameter::getDeclaringFunction()
ReflectionFunctionAbstract
ProxyGenerator::formatType(...)
ReflectionMethod
ReflectionFunction
/** * @return string|null */ private function getParameterType(ReflectionParameter $parameter) { if (! $parameter->hasType()) { return null; } return $this->formatType($parameter->getType(), $parameter->getDeclaringFunction(), $parameter); }
I'd propose a change from the above code to the code below:
/** * @return string|null */ private function getParameterType(ReflectionParameter $parameter) { if (! $parameter->hasType()) { return null; } $declaringFunction = $parameter->getDeclaringFunction(); assert($declaringFunction instanceof ReflectionMethod); return $this->formatType($parameter->getType(), $declaringFunction, $parameter); }
3v4l.org snippet
Of course the assertion will always be true, but this theoretical type mismatch was pointed out by my IDE, which confused me at first. In my opinion this would make the code more clean and prevent any future confusion about what type is expected.
@GameplayJDK it'd be better to just open the PR with the description from here :)
I'll edit it accordingly, thanks 👍
Hello everyone,
while working on #917 i noticed a missing
assert()
in the methodgetParameterType()
of theProxyGenerator
.The
ReflectionParameter::getDeclaringFunction()
method returns aReflectionFunctionAbstract
, the type hint ofProxyGenerator::formatType(...)
isReflectionMethod
, one of two possible implementations, the other isReflectionFunction
.I'd propose a change from the above code to the code below:
3v4l.org snippet
Of course the assertion will always be true, but this theoretical type mismatch was pointed out by my IDE, which confused me at first. In my opinion this would make the code more clean and prevent any future confusion about what type is expected.