Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112169
MIME-Version: 1.0
References: <CAM0CcxjF3TzcFZegM3KvA07K_dQPnN=Mp-kkYK94Mja487KKtQ@mail.gmail.com>
 <CAG9XoMQrp_SvoZ2Ls+=ybTeZYxDbyASda2wFu=zGKkFSwJ3yPw@mail.gmail.com> <CAFPFaM+8rSM4Meisr8Nwxu5DdA5=D+D7r2n6ptN4_W8hV3X9_Q@mail.gmail.com>
In-Reply-To: <CAFPFaM+8rSM4Meisr8Nwxu5DdA5=D+D7r2n6ptN4_W8hV3X9_Q@mail.gmail.com>
Date: Tue, 3 Nov 2020 21:35:40 +0200
Message-ID: <CAM0CcxhOyTAtYmowkej+C9N3-B8PcyovOdT_iOsLvHHHTDvL6A@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: Benjamin Morel <benjamin.morel@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007fa41c05b338f8a3"
Subject: Re: [PHP-DEV] Nullsafe
From: zsidelnik@gmail.com (Eugene Sidelnyk)

--0000000000007fa41c05b338f8a3
Content-Type: text/plain; charset="UTF-8"

About implemented, there were many implemented features, but not accepted.
I was very frustrated, when I knew that PHP could have
https://wiki.php.net/rfc/userspace_operator_overloading , and it was
already implemented.
But some people vote down, because they are "narrow-minded" and "have bad
preconceptions" and would like to find more things they like about the
feature.


On Tue, Nov 3, 2020 at 8:33 PM G. P. B. <george.banyard@gmail.com> wrote:

> On Tue, 3 Nov 2020 at 16:48, Benjamin Morel <benjamin.morel@gmail.com>
> wrote:
>
>> On Tue, 3 Nov 2020 at 17:38, Eugene Sidelnyk <zsidelnik@gmail.com> wrote:
>>
>> > I am wondering why don't we use ordinary `->` operator with safe null
>> > handling?
>>
>
> Implicit nullable is terrible, moreover I don't see why users should
> return null values more often.
> They serve their purpose but most of the time you can use another
> sane/safe default of the given
> property type.
>
> Moreover, I don't see the issue with another operator as it conveys
> *clear* intent especially in
> PHP as everything is `null` by default (might warn but still).
>
> *Technically* this isn't a BC break, but it's an enormous change of
> semantics for something
> which is worse IMHO. Also the operator has already been voted on,
> accepted, and implemented.
>
> Regards,
>
> George P. Banyard
>

--0000000000007fa41c05b338f8a3--