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.
```
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
