Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105354 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 60247 invoked from network); 23 Apr 2019 13:51:38 -0000 Received: from unknown (HELO more.superhosting.bg) (91.196.125.214) by pb1.pair.com with SMTP; 23 Apr 2019 13:51:38 -0000 Received: from [94.156.78.222] (port=37146 helo=[192.168.20.137]) by more.superhosting.bg with esmtpa (Exim 4.91) (envelope-from ) id 1hIt1n-00012P-Og; Tue, 23 Apr 2019 13:51:59 +0300 To: azjezz Cc: PHP Internals References: Message-ID: <9fee0f79-a77d-c0f1-ec24-efa4dd587f91@hristov.com> Date: Tue, 23 Apr 2019 13:51:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - more.superhosting.bg X-AntiAbuse: Original Domain - lists.php.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hristov.com X-Get-Message-Sender-Via: more.superhosting.bg: authenticated_id: php@hristov.com X-Authenticated-Sender: more.superhosting.bg: php@hristov.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [PHP-DEV] Object Type Casting Reloaded From: php@hristov.com (Andrey Hristov) 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 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 > > >