Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107688
MIME-Version: 1.0
References: <CAN=NbAL5r7m3hSi5FgobHpxoOL0Rei=QbqegtJsRi8WnE4kX9A@mail.gmail.com>
 <CA+kxMuSNp+DeE+8+Wb+xSyMU0g-gV-3P-NEV_wdLNbFOxZk0Eg@mail.gmail.com>
 <CAN=NbAJfHzxW+bLACOD=CVg7y3wV26s+tp_cxCvR44W+4OWJ5A@mail.gmail.com>
 <CAH0Uv3FO3aTHHzQ+dLLc-q-mJzdjkR3wz-GcKVhWJ7pUTL2sqQ@mail.gmail.com>
 <CAN=NbAKaE8z8NM1sr4UjHkTcCzs9QwEWoU8OE-r-tRqWGdhCpQ@mail.gmail.com>
 <CAH0Uv3F_PMcNr50cCCz0fh6LMoVDyMNhrKZ3X4bP9678T2ESKA@mail.gmail.com> <CAN=NbA+6jEyEWneLiCazzmrmr0XhXy9Du+dZ029EDuHoiM+xFg@mail.gmail.com>
In-Reply-To: <CAN=NbA+6jEyEWneLiCazzmrmr0XhXy9Du+dZ029EDuHoiM+xFg@mail.gmail.com>
Date: Thu, 24 Oct 2019 22:36:43 -0400
Message-ID: <CAN=NbAK7NrLg50YbCtkjU2XZKjif2R9Jbh9wn2W+GNvnX-ebfQ@mail.gmail.com>
To: Andreas Hennings <andreas@dqxtech.net>
Cc: Dan Ackroyd <Danack@basereality.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e88ced0595b3054b"
Subject: Re: [PHP-DEV] [RFC] anti-coalescing-operator
From: dohpaz@gmail.com (Ken Stanley)

--000000000000e88ced0595b3054b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This got rejected for being too large???

On Thu, Oct 24, 2019 at 10:05 PM Ken Stanley <dohpaz@gmail.com> wrote:

> Now we=E2=80=99re talking. :-)
>
> This example is better indeed.
>> But here I would prefer to have the ?-> operator proposed earlier
>> (nullsafe calls).
>>
>>          return $this->user?->getName();
>>
>
> Sure, but that limits you to use cases on the same object. With !?? You=
=E2=80=99d
> be free to both use the same object, OR to use a different construct base=
d
> on a semantically related (but technically different) construct: $userId
> !?? $this->getuser();  =E2=80=94 It=E2=80=99s an example, so don=E2=80=99=
t get too hung up on the
> color of the bike shed.
>
>
>> >>
>> >> 3. One purpose of the operator should be that you don't have to repea=
t
>> >> the variable. Here you do, e.g. $_SERVER['fname']
>> >>
>> >
>> > I'm not sure how that's necessarily a bad thing. Would you elaborate?
>> Is it simply a matter of writing the same characters twice? How is that
>> different than:
>> >
>> > if (isset($_SERVER['fname'])) {
>> >     $user->setName($_SERVER['fname']);
>> > }
>>
>> I thought you like brevity? "terse and simple"?
>> Ofc it is not just about typing more characters, but about having two
>> places that need to be updated if we change the value expression.
>> All the arguments for DRY apply.
>>
>
> To me, and I respect if this isn=E2=80=99t a popular opinion, DRY applies=
 to
> processes, logic, and constructs. Things like variables and non-logic is
> (again imo) a step too far.
>
> In other words, the repetition of a variable name in a finite scope as
> intended for this operator (ie within a line or two of each other) should
> not be an argument for being DRY.
>
> Again,
>
> if (isset($_POST[=E2=80=98field=E2=80=99]) {
>     $this->doSomething($_POST[=E2=80=98field=E2=80=99]);
> }
>
> Is absolutely no different than
>
> $_POST[=E2=80=98field=E2=80=99] !?? $this->doSomething($_POST[=E2=80=98fi=
eld=E2=80=99]);
>
> And the same goes for $foo !?? $foo->getBar(); .
>
>
>> And yes, with existing if/else code we would also have this kind of
>> repetition for this use case.
>> But if we introduce a new operator, we would expect this to go away,
>> wouldn't we?
>
>
> No. The aim is not to reduce variable usage. It=E2=80=99s to reduce boile=
r plate
> code for a very common, and unnecessarily verbose coding pattern. In othe=
r
> words, it=E2=80=99s syntactic sugar.
>
> Yes, I appreciate that =E2=80=9Csyntactic sugar=E2=80=9D may be considere=
d as a
> four-letter word by some, but that does not dismiss the usefulness of suc=
h
> syntax.
>
> The fact that it=E2=80=99s a counterpart to an existing syntax l, I belie=
ve,
> further warrants it=E2=80=99s inclusion into the language. Why should t w=
e have the
> ability to do something when a value is not null? Why should we be forced
> to be verbose about it?
>
> I refuse to accept the =E2=80=9Cthis can be done using if=E2=80=99s or &&=
=E2=80=9D argument,
> simply because operators like ?? and ?: already exist.
>
>
>> The repetition becomes more relevant if the expression we would repeat
>> is really long:
>>
>> isset($something['something']['something']['something']) !??
>> $something['something']['something']['something']->foo();
>
>
> This would be invalid because isset() returns Boolean. ?? deals with
> bulls, and naturally !?? deals with non-nulls. You=E2=80=99re thinking ?:=
 which
> deals with truthy/falsey values. That may be a separate (future) RFC. ;-)
>
>
>>
>> >
>> >>
>> >> 1.
>> >> If you would simply omit the line breaks in the first version, you
>> >> would get this:
>> >>
>> >>     if (isset($_SERVER['fname'])) $user->setName($_SERVER['fname']);
>> >>     if (isset($_SERVER['lname'])) $user->setName($_SERVER['lname']);
>> >>     if (isset($_SERVER['mname'])) $user->setName($_SERVER['mname']);
>> >>     if (isset($_SERVER['phone'])) $user->setName($_SERVER['phone']);
>> >>     if (isset($_SERVER['email'])) $user->setName($_SERVER['email']);
>> >
>> >
>> > Ugh! I just noticed that I mistakenly did not update the method names
>> for each line, so I can see how this might look like flow control. Those
>> methods should be setFirstName, setLastName, setMiddleName, setPhone, an=
d
>> setEmail respectively. My apologies.
>>
>> I meant "only control flow" in the sense that we are not returning a
>> value, or rather, we do not read the value.
>> Ofc it makes a more lively example to have different methods, but I
>> was looking past that already :)
>
>
> Well thank you for the latitude. As much as I=E2=80=99d like to have writ=
ten a
> perfect informal proposal, I=E2=80=99m not that lucky. :-)
>
> As far as flow control, let=E2=80=99s make no mistake, ??, ?:, and the id=
ea of !??
> are all succinct forms of flow control. To pretend otherwise is a bit
> naive. Their entire existence is purely syntactic sugar so we do not have
> keep writing the same boiler plate over and over.
>
> The goal here is to merely introduce a natural progression of ?? by
> offering the ability to do something when a non-null value exists. I
> understand it=E2=80=99s niche, but so is ?? for that matter.
>
>
>
>>
>> >
>> >>
>> >>
>> >> 2.
>> >> Instead of "abusing" your new operator, you could simply "abuse" the
>> >> old ternary ?: instead:
>> >>
>> >>     !isset($_SERVER['fname']) ?: $user->setName($_SERVER['fname']);
>> >>     !isset($_SERVER['lname']) ?: $user->setName($_SERVER['lname']);
>> >>     !isset($_SERVER['mname']) ?: $user->setName($_SERVER['mname']);
>> >>     !isset($_SERVER['phone']) ?: $user->setName($_SERVER['phone']);
>> >>     !isset($_SERVER['email']) ?: $user->setName($_SERVER['email']);
>> >>
>> >
>> > Re; #1 and #2 here: the same argument can be made for both ?? and ?:,
>> which again, has already passed muster and set precedent.
>> >
>>
>> As before, they were not really designed for this case.
>> But if we do use them, they already go a long way.
>>
>> >>
>> >> 3.
>> >> One way to not repeat the variable would be to introduce a temporary
>> >> local variable, like so:
>> >>
>> >>     if (NULL !=3D=3D $fname =3D $_SERVER['fname'] ?? NULL)
>> $user->setName($fname);
>> >
>> > The entire point of !?? would be to keep things terse and simple in
>> nature. Does it fit every possible use case? No. But neither do ?? and ?=
:.
>> And, like ?? and ?:, no one is required to use it if they feel being mor=
e
>> verbose makes sense for their needs.
>>
>> >
>> >>
>> >>
>> >> So, the operator would break out of the current expression context,
>> >> and produce a value one level up, a bit like a try/throw/catch would,
>> >> or like a break in switch.
>> >>
>> >
>> > Isn't this the same as the aforementioned null-safe operator [
>> https://wiki.php.net/rfc/nullsafe_calls]?
>>
>> Except that ?-> only works for method chaining, not for function args.
>> (as pointed out in a previous message)
>
>
> You=E2=80=99re right. I didn=E2=80=99t think my counter argument all the =
way through in
> your given example. But, for the sake of argument, at first glance your
> syntax makes zero sense because it=E2=80=99s (to me, a PHP and JS dev) no=
t a common
> paradigm. At least putting a ! in front of ?? has a natural association a=
nd
> does not require any esoteric knowledge.
>
>
>>
>> -- Andreas
>>
>> >
>> >>
>> >> This is just a basic idea, it still leaves a lot of questions open.
>> >> If the expression context is multiple levels deep, how many of these
>> >> levels are we breaking?
>> >>
>> >> I am not suggesting this is a good idea, but I think it is an
>> >> improvement to the original proposal.
>> >>
>> >> -- Andreas
>> >
>> >
>> >
>> > Thank you for the great feedback!
>
>
>
> So far it seems like the biggest concern(s) is that we would most likely
> repeat the use of variables (nothing new), and that there are other ways =
to
> do the same thing (again, nothing new). And of course the most valid
> argument of all: adding more operators to the soup mix. Personally, I don=
=E2=80=99t
> see these as show stoppers, at least given that the idea is not too wild
> and out there.
>
> I am going to assume at this point I should have enough feedback to
> warrant putting together a thorough RFC. But don=E2=80=99t let that stop =
anybody
> else from chiming in. I welcome the additional feedback.
>
> Seriously, thank you all for taking the time to help me defend my thesis
> (if you will).
>
> - Ken Stanley
>
>> --
> "Do not go gentle into that good night. Rage, rage against the dying of
> the light." =E2=80=94 Dylan Thomas
>
--=20
"Do not go gentle into that good night. Rage, rage against the dying of the
light." =E2=80=94 Dylan Thomas

--000000000000e88ced0595b3054b--