Hi,
On 23.04.19 г. 13:44 ч., azjezz wrote:
Hello Dan,
I don' think this a problem relating to just one use case, some PHP builtin
functions have weird union return types, where static analysis tools would warn
you about the return type being `string|bool`, when you are expecting `string`.
using type constrain :
```
$foo = substr($foo, 1, 3) as string;
// there's no need to check if `$foo` is false here.
```
this is easily solvable with the following (considering strict_types is
enabled)
function tostr(string $in) : string { return $in; }
$foo = tostr($foo);
Put it in a convenience namespace and that's it.
Cheers,
Andrey
Cheers,
- Saif
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, April 23, 2019 11:33 AM, Dan Ackroyd <dan...@basereality.com> wrote:
HI Benjamin,
Similar to the nullable casting idea, you're taking a problem caused
by your own code/framework, and then thinking it should be solved in
core, when a simple solution is available in user-land.
If you changed what you currently have:
$service = $diContainer->get('email.service');
to also take the expected class:
$service = $diContainer->get('email.service', EmailService::class);
And then check inside your 'DI container' whether the expected type is
returned, this solves the problem without needing new syntax.
btw I'm sure you're already aware of it, but this is using a
'dependency injector' as a service locator. If your current DI library
isn't powerful enough for you, rather than abusing it like this, I'd
recommend looking at a different one, like
https://github.com/rdlowrey/Auryn
Also, similar:
By the way, this RFC is a special case of something that could be far
more generic. If it was possible to register callbacks to be used when
casting, ...
Apparently this might not be possible as it's ambiguous....which is a shame.
cheers
Dan
Ack
On Mon, 22 Apr 2019 at 22:47, Benjamin Morel benjamin.mo...@gmail.com wrote:
Hi internals,
I'd like to revive an old discussion https://externals.io/message/67131 about
object type casting.
The idea would be to allow (ClassName) casting:
$service = (EmailService) $diContainer->get('email.service');
The above code would throw a TypeError if the value is not an instance of
the given class. I see the following advantages:
- Type safety: we can be sure that the value is of the correct type or that
we'll get an Error. This syntax allows to fail early if the variable
happens to not be of the expected type, and avoids much more verbose
checks;
- Static analysis: IDEs and static code analysis tools can now understand
the type of the variable, without having to resort to `@var` annotations.
These combine into a third advantage: readability. Today's equivalent of
the above one-liner could be:
/** @var EmailService $service */
$service = $diContainer->get('email.service');
if (! $service instanceof EmailService) {
throw new TypeError('Expected instance of EmailService, ...');
}
Which is a lot of boilerplate code that could be easily avoided by
introducing this new syntax.
Before moving forward and working on a formal RFC, I'd like to hear your
thoughts: what's your early feeling about this? Did I miss other
discussions around this subject? Are there any technical issues that come
to mind? Could this feature help the upcoming JIT compiler produce more
efficient machine code by knowing the type of the variable at compile time?
etc.
Note: "casting" might not be the perfect name here as what we're really
doing is a type check, but this reuses the type casting syntax and
resembles Java's object casting.
Thank you,
Ben
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
