Re: [PHP-DEV] Object Type Casting Reloaded

> On 23 Apr 2019, at 21:54, Benjamin Morel wrote: > > @Stephen Reay > >> In languages without type hinting (e.g. JavaScript) - the “boiler plate” > you’re trying to remove is also common, e.g. using `typeof` in JavaScript. > > It's also very common to *not* check types in JavaScript... I ass

[PHP-DEV] Re: [RFC VOTE] Unbundle ext/interbase

Hi Den tir. 9. apr. 2019 kl. 20.02 skrev Kalle Sommer Nielsen : > > Evening Internals > > Apologies for the one day delay, but the voting for the RFC "Unbundle > ext/interbase" is open[1]. There is only one voting choice, which > decides if the extension should be moved to PECL. > > Since this sta

Re: [PHP-DEV] Object Type Casting Reloaded

@Stephen Reay > In languages without type hinting (e.g. JavaScript) - the “boiler plate” you’re trying to remove is also common, e.g. using `typeof` in JavaScript. It's also very common to *not* check types in JavaScript... I assume the absence of type hints is partly responsible for this, and a

Re: [PHP-DEV] Object Type Casting Reloaded

> On 23 Apr 2019, at 21:02, Benjamin Morel wrote: > > It's exactly the purpose of the proposal: avoid this boilerplate. For the > same reason you probably write: > Replacing 1 line of “boiler plate” with a *different* line of less-obvious “boiler plate” is not an improvement IMO. > The cur

Re: [PHP-DEV] Object Type Casting Reloaded

@Stephen Reay > And as I said before, I can’t understand how that is supposed to be better than just doing what works now, using instanceof to check the type inside the block: > if (! $foo instanceof Foo) { throw new TypeError(…); } > At least with the above, it’s obvious what is happening. It's

Re: [PHP-DEV] Object Type Casting Reloaded

On 23/04/2019 14:39, Mark Randall wrote: It keeps coming back to the feature we've all been praying to the PHP Gods for... generics. Replying to myself (sorry). I just wanted to point out that the same syntax would also solve your other issue from the nullable casts thread: function ncast($

Re: [PHP-DEV] Object Type Casting Reloaded

> On 23 Apr 2019, at 19:32, Benjamin Morel wrote: > > I'm sorry, I still don't understand what the issue with foreach is? As I said > before, the proposed syntax does not aim to be used inside the foreach () > parentheses, but rather as an explicit declaration inside the foreach {} > block.

Re: [PHP-DEV] Object Type Casting Reloaded

@Mark Randall > It keeps coming back to the feature we've all been praying to the PHP > Gods for... generics. > $x = cast($obj); I did not think about using generics for this, but indeed this could work. It's only reasonably verbose, easily implemented in userland, and should be usable both by s

Re: [PHP-DEV] Object Type Casting Reloaded

On 23/04/2019 13:32, Benjamin Morel wrote: Aw. I did not think about a possible conflict here, thanks for bringing this up! It keeps coming back to the feature we've all been praying to the PHP Gods for... generics. function cast(object $obj): T { if ($obj instanceof T) { return $obj;

Re: [PHP-DEV] Object Type Casting Reloaded

@Nikita Popov > It's not possible to use (ClassName) as a cast syntax, because it is ambiguous. Aw. I did not think about a possible conflict here, thanks for bringing this up! @Stephen Reay > My objection to `as` is that it specifically prevents (or makes very confusing) the `foreach` use I

Re: [PHP-DEV] 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` : `functio

Re: [PHP-DEV] Object Type Casting Reloaded

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

Re: [PHP-DEV] Object Type Casting Reloaded

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

Re: [PHP-DEV] Object Type Casting Reloaded

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'); t

Re: [PHP-DEV] Object Type Casting Reloaded

Hello Nikita, I would love to hear your opinion on the `as` syntax from Hack, and whether it can be used in PHP the same way or would it be an issue. Cheers, - Saif Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, April 23, 2019 10:16 AM, Nikita Popov wrote: >

Re: [PHP-DEV] Object Type Casting Reloaded

Hi, maybe with short closures this will be pretty easy to implement by injecting a short closure that expects the return type to be of the type to be casted and to return it. Something in the like of : $service = (fn(EmailService $s):EmailService => $s ;)($diContainer->get('email.service'))

Re: [PHP-DEV] Object Type Casting Reloaded

> On 23 Apr 2019, at 16:03, Benjamin Morel wrote: > > > I like the idea but I find the syntax (both suggestions) less than great, > > given that there’s already “ensure a type” syntax, and both suggestions are > > already used for other things (casting and foreach) > > Note that we already us

Re: [PHP-DEV] Object Type Casting Reloaded

On Mon, Apr 22, 2019 at 11:48 PM Benjamin Morel wrote: > Hi internals, > > I'd like to revive an old discussion > about > object type casting. > > The idea would be to allow (ClassName) casting: > > $service = (EmailService) $diContainer->get('email.servic

Re: [PHP-DEV] Object Type Casting Reloaded

Hi all, thanks for the valuable feedback! @Stephen Reay: > I like the idea but I find the syntax (both suggestions) less than great, given that there’s already “ensure a type” syntax, and both suggestions are already used for other things (casting and foreach) Note that we already use `as` in o

Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator

On Mon, Apr 22, 2019 at 5:28 PM Sara Golemon wrote: > On Tue, Apr 9, 2019 at 4:54 AM Nikita Popov wrote: > >> Inspired by Bob's recent RFC for concat precedence, I'd like to propose a >> deprecation and removal of the left-associative behavior of ternaries. >> Instead, explicit parentheses shoul

[PHP-DEV] [VOTE] Deprecate left-associative ternary

Hi internals, I've opened voting on the RFC to deprecate & remove left associative ternary without explicit parentheses. The vote ends 2019-05-07: https://wiki.php.net/rfc/ternary_associativity The RFC stays as originally proposed: The associativity of the ternary will *not* be changed to right-

[PHP-DEV] [VOTE] Always generate fatal error for incompatible method signatures

Hi internals, I've opened the vote on the LSP error RFC. Voting is open until 2019-05-07. https://wiki.php.net/rfc/lsp_errors Regards, Nikita