On Dec 9, 2014, at 3:18 PM, Andrea Faulds <a...@ajf.me> wrote: >> On 9 Dec 2014, at 23:07, Josh Watzman <jwatz...@fb.com> wrote: >> >> Hey internals! A useful feature that Hack picked up in the last few months >> are "nullsafe calls", a way of propagating failure forward in a series of >> chained method calls to the end of the whole computation, getting rid of a >> lot of the boilerplate in the middle. I think the feature would be a good >> one for PHP as well, so I'm submitting this RFC to add it -- you can see the >> RFC itself for a full discussion of the motivation for the feature, as well >> as the feature itself: >> >> https://urldefense.proofpoint.com/v1/url?u=https://wiki.php.net/rfc/nullsafe_calls&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=NOz6YOAf%2F6vcJtVVDrd%2F2w%3D%3D%0A&m=PWfP%2BxZeAyjdTrP6VD3DSUmxrBjiUYvk0TNF5G5e6Ag%3D%0A&s=16ce2443111cdb22b84068fd36e93c14d68190e3fe9a2302cf576464b71d28bd > > Hi! > > In a way, this would complement the ?? null coalescing operator we’re adding. > :) > > Two thoughts, though: > > 1) Wouldn’t it be useful to also have this for properties? If you’re going > down a long list of property accesses, $foo?->bar?->qux is probably nicer > than if ($foo !== NULL && $foo->bar !== NULL) { $foo->bar->qux; … } - on the > other hand, the ?? operator partly covers this and even handles arrays, as > you can do $foo->bar[‘elePHPant']->qux[‘boop’] ?? NULL already. We also > couldn’t add something like ?-> for arrays, as the ?[] syntax is ambiguous > (looks like ternary with short array syntax).
Property access could be useful as well, I just didn't want to deal with it for the first version of the RFC. It's actually already listed in "future scope". :) If this method call portion goes well, I'd be willing to submit an RFC/implementation for that as well, but I wanted to get method calls done first. (It's also somewhat less clearly useful than method calls, especially with '??' as you point out, which is why I went with method calls first :)) > 2) It’d probably be better if you made a language specification patch before, > not after, the RFC is accepted. Having to specify the syntax and semantics > formally can make what the operator does clearer and help to spot issues. > Plus, going forward, the language specification should not be an afterthought. Definitely not an afterthought. I just want to get through all of the "not clear if it's going to work" bits -- first, the feasibility of the actual implementation, then whether the RFC got good reception on internals. I'll make sure to have a spec diff before the RFC goes up for a vote -- does that sound good? > Otherwise, though, I’m in favour of this change. Thanks for the feedback! Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
