Re: Object Type Casting Reloaded

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 <php@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 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