Re: [PHP-DEV] [RFC] anti-coalescing-operator

  107679
October 24, 2019 22:49 dohpaz@gmail.com (Ken Stanley)
On Thu, Oct 24, 2019 at 6:01 PM Mark Randall <marandall@php.net> wrote:

> On 24/10/2019 22:52, Ken Stanley wrote: > > I'm more interested in having a negation operator for the null-coalescing > > operator, especially since cognatively it should be easy to discern what > it > > does. > > At the point your syntax ends up looking like you're screaming at your > source code, I think easy cognition has likely gone out the window. > > There are plenty of much more expressive ways of doing this without > introducing new syntax IMHO.
Mark, Yes, the operator would be new as in it doesn’t exist, but it’s not new in the fact that it is simply a negation of an existing operator. I would be keen to see the more expressive techniques that retain the succinctness of having a not-null coalescing operator. I can certainly appreciate the hesitation to introduce more syntax. However, I am arguing that this particular case is merely an extension (compliment) of the existing null-coalescing operator and therefore it’s not truly new; especially since !== null is a very common comparison used in programming.
> > Mark Randall > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
Thank you.
> `|>` is not something new it appeared in many languages long time ago (in some forms). JavaScript also has a proposal of it. And PHP someone has
already proposed one. Kosit, Thank you. In this case I’d still argue that my proposed operator, for what I’m intending it to be, is the better solution. I appreciate that my example might not have been the best, but I wanted to demonstrate one possible usage out of many that could be used to easily solve the same problem of needing to do “something” based on a non-null value. Thank you! -- "Do not go gentle into that good night. Rage, rage against the dying of the light." — Dylan Thomas
  107686
October 25, 2019 00:54 mike@newclarity.net (Mike Schinkel)
> On Oct 24, 2019, at 6:49 PM, Ken Stanley <dohpaz@gmail.com> wrote: > I would be keen to see the more expressive techniques that retain the > succinctness of having a not-null coalescing operator.
When I read your first example, I immediately thought I would handle your example in this way: $user->setFName( $_SERVER[ 'fname' ] ?? null ); $user->setLName( $_SERVER[ 'lname' ] ?? null ); $user->setMName( $_SERVER[ 'mname' ] ?? null ); $user->setPhone( $_SERVER[ 'phone' ] ?? null ); $user->setEmail( $_SERVER[ 'email' ] ?? null ); Admittedly it does not require the functionality of your proposed operator, and it delegates the null handling to the set*() methods, but it is more succinct and does not require duplicating `$_SERVER[ '*' ]`, so it would be a winner for me. I also do not mind putting more effort into writing functions if it means less effort required to call the functions. But maybe that is just me? Your 2nd example was more compelling for me, but Sara's nullsafe calls RFC uses a syntax that is more clear and obvious to me. Is there a 3rd or 4th use-case you have that are unlike the first two? -Mike
  107687
October 25, 2019 02:31 dohpaz@gmail.com (Ken Stanley)
On Thu, Oct 24, 2019 at 8:54 PM Mike Schinkel <mike@newclarity.net> wrote:

> On Oct 24, 2019, at 6:49 PM, Ken Stanley <dohpaz@gmail.com> wrote: > I would be keen to see the more expressive techniques that retain the > succinctness of having a not-null coalescing operator. > > > > When I read your first example, I immediately thought I would handle your > example in this way: > > $user->setFName( $_SERVER[ 'fname' ] ?? null ); > > $user->setLName( $_SERVER[ 'lname' ] ?? null ); > > $user->setMName( $_SERVER[ 'mname' ] ?? null ); > > $user->setPhone( $_SERVER[ 'phone' ] ?? null ); > > $user->setEmail( $_SERVER[ 'email' ] ?? null ); > > > Admittedly it does not require the functionality of your proposed > operator, and it delegates the null handling to the set*() methods, but it > is more succinct and does not require duplicating `$_SERVER[ '*' ]`, so > it would be a winner for me. > > The problem here is that null values may or may not be valid inputs for the
setters. Assuming for one moment that the setters do allow null, what does that mean for the underlying model? Is null to mean that it’s under? Or is null just another possible value? Using !?? to only call a setter if there is a non-null value is very important in many circumstances - my original example was to illustrate a succinct way to implement a REST PATCH HTTP request, where only fields with values get updated - in other words, you don’t want to set other fields to null because you want to retain their original values; not overwrite them. Overwriting values with null is a valid use case, but not for this operator (not necessarily). Null means nothing, no value, or better: not answered. This is distinctly different than ‘’, false, or 0. Those are explicit responses to a question. Null Just means no data.
> I also do not mind putting more effort into writing functions if it means > less effort required to call the functions. But maybe that is just me? > > But if you don’t have to, then why would you? I’m all for clarity and
expressiveness. But I’m also for simplicity and being as succinct as practically possible.
> Your 2nd example was more compelling for me, but Sara's nullsafe calls RFC > uses a syntax that is more clear and obvious to me. > > I am a Symfony developer, and as such I like to utilize annotations (bear
with me). They have a ParamConverter annotation that can automatically look up an entity based on the type hint given to a controller action. If the parameter is null able, I may need to add an if condition to look up a sane default value when the parameter comes through as null. It would be much more succinct (and less error prone) to be able to say something like /** * @ParamConverter(name=“application”, ...) */ public function myAction(Request $request, Application $application) { $user = $application->getUser() !?? $this->getUser(); // ... do something with user, without worrying about it being null. }
> Is there a 3rd or 4th use-case you have that are unlike the first two? > > I will let you know when I think of them. I totally understand how much
easier it is for others to conceptualize with good examples. I want to be concise and relevant at the same time, and that’s actually pretty difficult. :-)
> -Mike > > > > -- "Do not go gentle into that good night. Rage, rage against the dying of the
light." — Dylan Thomas
  107689
October 25, 2019 06:42 claude.pache@gmail.com (Claude Pache)
> Le 25 oct. 2019 à 04:31, Ken Stanley <dohpaz@gmail.com> a écrit : > > If the parameter is null able, I may need to add an if condition to look up > a sane default value when the parameter comes through as null. It would be > much more succinct (and less error prone) to be able to say something like > > /** > * @ParamConverter(name=“application”, ...) > */ > public function myAction(Request $request, Application $application) > { > $user = $application->getUser() !?? $this->getUser(); > > // ... do something with user, without worrying about it being null. > } >
Did you meant: $user = ($application ?? $this)->getUser(); ? —Claude