On Dec 12, 2014, at 11:09 AM, Josh Watzman wrote:
> On Dec 10, 2014, at 11:24 PM, Stanislav Malyshev wrote:
>
>>> the real-world code I've seen, it is the least confusing. (I'll see
>>
>> Which real-world code you are talking about? Examples please.
>
> I'm having trouble digging any up -- FB
On Dec 10, 2014, at 11:24 PM, Stanislav Malyshev wrote:
>> the real-world code I've seen, it is the least confusing. (I'll see
>
> Which real-world code you are talking about? Examples please.
I'm having trouble digging any up -- FB's codebase has >10k occurrences of this
feature and I have ye
Hi Thomas,
> On 12 Dec 2014, at 15:42, Thomas Bley wrote:
>
> 1) I think it would be better to have ObjectSafe Calls, e.g.
>
> class User {
> ...
> public function delete() {
>// delete ...
> }
> }
> class Users {
> public function find($id) {
>if ($this->db->query(...)) return new
Hello Josh,
1) I think it would be better to have ObjectSafe Calls, e.g.
class User {
...
public function delete() {
// delete ...
}
}
class Users {
public function find($id) {
if ($this->db->query(...)) return new User($id);
return 'not found';
}
}
$users = new Users();
$r
I agree, doing lots of if statements gets bloated. Someone would only
use this method if they was comfortable with it either returning null or
the desired result.
On 11/12/2014 16:00, Rowan Collins wrote:
guilhermebla...@gmail.com wrote on 11/12/2014 15:57:
Not trying to demerit the proposal,
guilhermebla...@gmail.com wrote on 11/12/2014 15:57:
Not trying to demerit the proposal, but accepting ?-> and black magic just
seems wrong, very wrong.
You need to write defensive code, not rely on the language to do that for
you.
But surely if you're consciously deciding to use this feature,
Hi,
Not trying to demerit the proposal, but accepting ?-> and black magic just
seems wrong, very wrong.
You need to write defensive code, not rely on the language to do that for
you.
[]s,
On Thu, Dec 11, 2014 at 2:35 AM, Stanislav Malyshev
wrote:
> Hi!
>
> > First, how is this substantially di
Hi!
> First, how is this substantially different from catching an
> exception? With Nikita’s Exceptions in the Engine RFC
> (https://wiki.php.net/rfc/engine_exceptions_for_php7), something like
> this would be possible:
>
> try { return $foo->bar()->qux()->elePHPant()->dance(); } catch
> (EngineE
Hi!
> I think it's confusing the other way, and "instead of raising a fatal
> for calling a method on null, it returns null" is just as simple of
> an explanation.
What is confusing in "no call is made, so nothing is evaluated" or in
"as soon as we see null, we stop and return null"? I can not be
Hi!
> Take a look at the "short circuit" section where I specifically
> address this. It was done to make it easier to reason about in a
> side-effect-ful language like PHP. With this behavior, when you see
>
> $x?->f(g(), h())
I think this is weird magic behavior which should not be part of PHP
On Dec 10, 2014, at 4:12 PM, Christoph Becker wrote:
> Josh Watzman wrote:
>
>> However, for a lot of failures, I don't feel that exceptions are
>> appropriate. I tend to only use them for exceptional behavior --
>> usually, some failure that needs to be propagated up a few levels up
>> the sta
Josh Watzman wrote:
> However, for a lot of failures, I don't feel that exceptions are
> appropriate. I tend to only use them for exceptional behavior --
> usually, some failure that needs to be propagated up a few levels up
> the stack, to an appropriate error boundary. This doesn't necessarily
>
On Dec 10, 2014, at 12:30 PM, Robert Stoll wrote:
> I stick with it, evaluating it does not make sense IMO. If I want to execute
> it in any case then I would do something
> like this currently
>
> $g = g();
> $h = h();
> if($x !== null){
> $x->foo($g, $h)->bar(baz());
> }
>
> And with the ?-
>> .huh? I'm not talking about exceptions the object itself throws. In PHP 7,
>> if Nikita's RFC passes, trying to call a method on
>> NULL will throw an exception. That largely negates the need for a special
>> operator, since you can just catch the exception.
>>
>> Thanks.
>> --
>> Andrea Fau
Hi again.
> On 10 Dec 2014, at 19:11, Josh Watzman wrote:
>
> On Dec 10, 2014, at 9:19 AM, Andrea Faulds wrote:
>
>> First, how is this substantially different from catching an exception? With
>> Nikita’s Exceptions in the Engine RFC, something like this would be possible:
>>
>> try {
>>
On Dec 10, 2014, at 9:19 AM, Andrea Faulds wrote:
> Hi again,
>
> I was in favour of this, but upon further thought, I’m not sure I am. I
> remember I also initially liked it in Hack and then lost interest.
>
> First, how is this substantially different from catching an exception? With
> Niki
On Dec 10, 2014, at 8:17 AM, Robert Stoll wrote:
> First of all, I like the RFC, I think as well that it is a useful feature for
> PHP and I already have it on my wish list
> ;)
>
> Yet, either I misunderstand the section about short circuiting or I propose
> to change the behaviour.
>
> "If
Andrea Faulds wrote on 10/12/2014 17:19:
Finally, this may encourage bad code. As someone helpfully pointed out in the
reddit discussion (http://redd.it/2ot15u), this encourages breaking the Law of
Demeter, i.e. that objects should only talk to their immediate friends.
Usually, long chains of
> On 9 Dec 2014, at 23:07, Josh Watzman 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 b
Hi!
> On 9 Dec 2014, at 23:31, Josh Watzman wrote:
>
>> 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. P
On Dec 9, 2014, at 3:18 PM, Andrea Faulds wrote:
>> On 9 Dec 2014, at 23:07, Josh Watzman 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
> On 9 Dec 2014, at 23:07, Josh Watzman 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 b
22 matches
Mail list logo
