Hello Andery.
yes that's possible, but would need a function for each type, or we can do :
https://3v4l.org/6B3hA
but this is still not type-safe, as we won't be able to type hint it correctly
without using generics + `typename` type that exists in Hack.
using generics + `typename` : `function check<T>(mixed $var, typename<T>
$type): T`
Cheers,
- Saif
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, April 23, 2019 11:51 AM, Andrey Hristov <p...@hristov.com> wrote:
> 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
