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
