Re: Object Type Casting Reloaded

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 <Danack@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.morel@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