Native type hints
zerkms opened this issue · comments
Given now 1838a0f only php>=7.2 is supported, how about switching to native type hints for arguments and return values where possible?
What would be the benefit of adding that?
Native php runtime checks.
That is both slower and gives us less control over the exception message. And other drawback is that it would break BC.
Since no benefits has been provided, I’ll close this issue.
That is both slower and gives us less control over the exception message.
wut
/**
* @psalm-pure
* @psalm-assert non-empty-string $value
*
* @param mixed $value
* @param string $message
*
* @throws InvalidArgumentException
*/
public static function stringNotEmpty($value, $message = '')
{
static::string($value, $message);
static::notEq($value, '', $message);
}vs (php7)
/**
* @psalm-pure
* @psalm-assert non-empty-string $value
*
* @param mixed $value
* @param string $message
*
* @throws InvalidArgumentException
*/
public static function stringNotEmpty($value, string $message = ''): void
{
static::string($value, $message);
static::notEq($value, '', $message);
}vs (php8)
/**
* @psalm-pure
* @psalm-assert non-empty-string $value
*
* @throws InvalidArgumentException
*/
public static function stringNotEmpty(mixed $value, string $message = ''): void
{
static::string($value, $message);
static::notEq($value, '', $message);
}Try to use more words. It is easier to understand you.
I don't see how the code examples you provided would give any real benefit. I don't think it is worth the BC break.
I don't think it is worth the BC break.
What BC break are you talking about?
would give any real benefit
it makes no sense to not use php built-in type system. What's the point to use phpdoc if you can express (most of the things) using the native language constructs?
/cc @Ocramius Marco could you please help me here?
What BC break are you talking about?
Narrowing the return types: https://3v4l.org/UBo3s
it makes no sense to not use php built-in type system. What's the point to use phpdoc if you can express (most of the things) using the native language constructs?
Is the main benefit that "it make no sense not to use it"?
Can you answer this very straight forward question:
How does signature stringNotEmpty(mixed $value, string $message = '') improve the user experience or performance compared to stringNotEmpty($value, $message = '') + doc block?
Narrowing the return types
The project was never designed for extending and overriding its static methods. If somebody abused what was not part of the contract - it's solely their problem.
improve the user experience
the earlier the type mismatch is detected - the easier it is to fix it.
What's the point to use non-standardised dialect when the language provide you the standard official tool?
Who at this very point makes project-wide decisions? Is it only you @Nyholm?
We have to think of Stringable class sent in the $message. If the caller is on strict_types it's a BC break too.
@orklah $message is annotated as string. Which means - the API only guarantees it would only work as expected if you pass a string there.
The project was never designed for extending and overriding its static methods. If somebody abused what was not part of the contract - it's solely their problem.
Though, it is a use case. We should not discard this just because you dont think that is the way to use the library.
the earlier the type mismatch is detected
You should run a static tool to analyse your code. So doc blocks or annotations doesn't really matter. If you want to discover in in runtime, I assume are referring to "earlier" as in the stringNotEmpty() as in "method signature" rather than "method body". That is the same from the user's point of view.
What's the point to use non-standardised dialect when the language provide you the standard official tool?
Are you referring to @param string $message? That is quite standard for the past 10 year..
Who at this very point makes project-wide decisions? Is it only you @Nyholm?
No, there is a few of us. But none will accept a feature that breaks BC or does not bring any value.
We should not discard this just because you dont think that is the way to use the library.
then literally any change (including a bugfix) is a BC.
No, there is a few of us. But none will accept a feature that breaks BC or does not bring any value.
Okay, can we please hear from other members then?
@orklah
$messageis annotated asstring. Which means - the API only guarantees it would only work as expected if you pass a string there.
This is a bold affirmation, given there was no way to describe a class with __toString in PHPDoc. Any change in an API is a BC break. This means it would need a new major version. Major version means every user has to take time to look at the changelog, check their usages and fix if needed before upgrading. For a package of this scale, this is probably literaly dozens of thousands dollars of developer time spent to make the API look nicer. I'm not saying we should not go there eventually, but this would have to ship with some other major changes to make sure not to waste everybody's time.
I'm not saying they are, I'm saying there was no good way for a library to document the difference. Hence, for the user, it might as well have been.
I'm not saying they are, I'm saying there was no good way for a library to document the difference. Hence, for the user, it might as well have been.
The point is that current implementation will fail Assert::string() for objects having __toString()
I'm not saying they are, I'm saying there was no good way for a library to document the difference. Hence, for the user, it might as well have been.
The point is that current implementation will fail
Assert::string()for objects having__toString()
We were talking about $message, not the actual string for string assertion. Anyway, this makes no difference because making the implementation fail another way would be a BC break too.