Re: [RFC] anti-coalescing-operator

From: Date: Thu, 24 Oct 2019 22:02:52 +0000
Subject: Re: [RFC] anti-coalescing-operator
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-107677@lists.php.net to get a copy of this message
Hi Ken |> 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. https://github.com/tc39/proposal-pipeline-operator https://wiki.php.net/rfc/pipe-operator Cheers On Fri, Oct 25, 2019 at 4:53 AM Ken Stanley <dohpaz@gmail.com> wrote: > > On Thu, Oct 24, 2019 at 5:19 PM Kosit Supanyo <webdevxp.com@gmail.com> > wrote: > >> Hi Ken >> >> I totally agree with Andreas especially: >> >> One purpose of the operator should be that you don't have to repeat >>> the variable. Here you do, e.g. $_SERVER['fname'] >> >> >> But if this operator provide some way not to repeat the variable it will >> make sense. For example: >> >> $_SERVER['fname'] !?? $user->setName($$) >> > > I asked Andreas for their opinion on why this is bad in this context? > Especially since if I were to use a traditional ternary or if condition, > then I'd still be repeating the variable. > > >> >> But I think this functionality should be of something like pipeline >> operator: >> >> // send tmp variable to the next expression unconditionally >> $ret = $_SERVER['fname'] |> $user->setName($$); >> // send tmp variable to the next expression only when $_SERVER['fname'] >> is set. >> $ret = $_SERVER['fname'] ?|> $user->setName($$); >> >> Also the syntax like above will be consistent with the proposed >> safe-navigation operators. >> > > 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. I've personally not seen |>, and I'd be confused as to what it does > (e.g., is it a bitwise OR on a greater than comparison?). > > Thank you! The idea of $$ is neat, but not quite what I'm trying to > achieve here. If anything, wouldn't that facilitate a different RFC? > > - Ken Stanley > >

« previous php.internals (#107677) next »