On Wed, Oct 30, 2019 at 7:35 AM Peter Bowyer
wrote:
> On Fri, 25 Oct 2019 at 00:28, Sara Golemon wrote:
>
>> At the risk of hijacking, @matthewrask asked me about ?-> a couple weeks
>> ago (Javascript is making this one popular), and I threw together a rough
>> PoC at
>>
On Fri, 25 Oct 2019 at 00:28, Sara Golemon wrote:
> At the risk of hijacking, @matthewrask asked me about ?-> a couple weeks
> ago (Javascript is making this one popular), and I threw together a rough
> PoC at
> https://github.com/php/php-src/compare/master...sgolemon:null-coalesce
> which
> I
> Le 25 oct. 2019 à 04:36, Ken Stanley a écrit :
>
> 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:
On Fri, 25 Oct 2019 at 12:27, Andreas Hennings wrote:
>
> On Fri, 25 Oct 2019 at 12:21, Rowan Tommins wrote:
> >
> > On Thu, 24 Oct 2019 at 22:20, Kosit Supanyo wrote:
> >
> > > But I think this functionality should be of something like pipeline
> > > operator:
> > >
> > > // send tmp variable
On Fri, 25 Oct 2019 at 12:21, Rowan Tommins wrote:
>
> On Thu, 24 Oct 2019 at 22:20, Kosit Supanyo wrote:
>
> > But I think this functionality should be of something like pipeline
> > operator:
> >
> > // send tmp variable to the next expression unconditionally
> > $ret = $_SERVER['fname'] |>
> Le 25 oct. 2019 à 01:23, Sara Golemon a écrit :
>
> Just testing the waters: Is there any appetite to have AND and OR behave
> more like Pythons operator?
> Instead of now:
> (a or b) => bool(true) if either of a or b are true
> (a and b) => bool(true) is either of a or b are true
>
>
On Thu, 24 Oct 2019 at 22:20, Kosit Supanyo wrote:
> 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
On Fri, 25 Oct 2019 at 03:37, Ken Stanley wrote:
> This got rejected for being too large???
>
If you trim the quotes in your replies to just the parts needed for
context, it keeps the message shorter, and makes it much easier to read
through.
> > The fact that it’s a counterpart to an
> Le 25 oct. 2019 à 04:31, Ken Stanley 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
>
> /**
>
This got rejected for being too large???
On Thu, Oct 24, 2019 at 10:05 PM Ken Stanley wrote:
> Now we’re talking. :-)
>
> This example is better indeed.
>> But here I would prefer to have the ?-> operator proposed earlier
>> (nullsafe calls).
>>
>> return $this->user?->getName();
>>
>
On Thu, Oct 24, 2019 at 8:54 PM Mike Schinkel wrote:
> On Oct 24, 2019, at 6:49 PM, Ken Stanley 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
> On Oct 24, 2019, at 6:49 PM, Ken Stanley 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(
> On Oct 24, 2019, at 8:03 PM, Andreas Hennings wrote:
>
> On Fri, 25 Oct 2019 at 01:28, Sara Golemon wrote:
>>
>> https://wiki.php.net/rfc/nullsafe_calls
>
> ?-> is a great idea.
Totally agree, that would be nice.
> The problem is this only works for method chaining, not for function
>
On Thu, 24 Oct 2019 at 23:49, Ken Stanley wrote:
>
> On Thu, Oct 24, 2019 at 4:29 PM Andreas Hennings wrote:
>>
>> On Thu, 24 Oct 2019 at 20:59, Ken Stanley wrote:
>> >
>> > On Thu, Oct 24, 2019 at 1:33 PM Dan Ackroyd wrote:
>> >
>> > > On Thu, 24 Oct 2019 at 18:21, Ken Stanley wrote:
>> > >
On Fri, 25 Oct 2019 at 01:28, Sara Golemon wrote:
>
> On Thu, Oct 24, 2019 at 12:46 PM Stephen Reay
> wrote:
>
> > This sounds like an alternative approach (for solving the same basic
> > problem) to the nullsafe operator discussed a while back, no?
>
> https://wiki.php.net/rfc/nullsafe_calls
>
On Fri, 25 Oct 2019 at 01:24, Sara Golemon wrote:
>
> On Thu, Oct 24, 2019 at 4:55 PM Ken Stanley wrote:
>
> > > isset($_SERVER['fname']) && $user->setName($_SERVER['fname']);
> > >
> > > Will return boolean.
> > >
> >
> > Just testing the waters: Is there any appetite to have AND and OR behave
On Thu, Oct 24, 2019 at 12:46 PM Stephen Reay
wrote:
> This sounds like an alternative approach (for solving the same basic
> problem) to the nullsafe operator discussed a while back, no?
https://wiki.php.net/rfc/nullsafe_calls
>
> At the risk of hijacking, @matthewrask asked me about ?-> a
On Thu, Oct 24, 2019 at 4:55 PM Ken Stanley wrote:
> > isset($_SERVER['fname']) && $user->setName($_SERVER['fname']);
> >
> > Will return boolean.
> >
>
> Just testing the waters: Is there any appetite to have AND and OR behave
more like Pythons operator?
Instead of now:
(a or b) => bool(true)
On Thu, Oct 24, 2019 at 6:01 PM Mark Randall 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
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
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
On Thu, Oct 24, 2019 at 5:31 PM Kosit Supanyo
wrote:
> Hi Bruce
>
> If I understand correctly.
>
> $_SERVER['fname'] !?? $user->setName($_SERVER['fname']);
>
>
> Will return the result of $user->setName($_SERVER['fname']) if
> $_SERVER['fname'] is set or null if not set. While:
>
>
On Thu, Oct 24, 2019 at 5:19 PM Kosit Supanyo
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
On Thu, Oct 24, 2019 at 4:29 PM Andreas Hennings
wrote:
> On Thu, 24 Oct 2019 at 20:59, Ken Stanley wrote:
> >
> > On Thu, Oct 24, 2019 at 1:33 PM Dan Ackroyd
> wrote:
> >
> > > On Thu, 24 Oct 2019 at 18:21, Ken Stanley wrote:
> > > >
> > > > Since PHP 7.0 brought forward the Null Coalescing
Hi Bruce
If I understand correctly.
$_SERVER['fname'] !?? $user->setName($_SERVER['fname']);
Will return the result of $user->setName($_SERVER['fname']) if
$_SERVER['fname'] is set or null if not set. While:
isset($_SERVER['fname']) && $user->setName($_SERVER['fname']);
Will return
Hi Ken
> $_SERVER['fname'] !?? $user->setName($_SERVER['fname']);
> $_SERVER['lname'] !?? $user->setName($_SERVER['lname']);
> $_SERVER['mname'] !?? $user->setName($_SERVER['mname']);
> $_SERVER['phone'] !?? $user->setName($_SERVER['phone']);
>
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'] !??
On Thu, 24 Oct 2019 at 20:59, Ken Stanley wrote:
>
> On Thu, Oct 24, 2019 at 1:33 PM Dan Ackroyd wrote:
>
> > On Thu, 24 Oct 2019 at 18:21, Ken Stanley wrote:
> > >
> > > Since PHP 7.0 brought forward the Null Coalescing Operator (??), writing
> > > more succinct code for how to handle null
Hi Ken,
This is definitely an interesting idea, and when described as "the
opposite of ??" the !?? syntax makes sense.
Looking at the example, though, the "negating" part becomes a bit confusing.
The verbose form reads naturally as a positive assertion - "if this is
set, do this":
On Thu, Oct 24, 2019 at 1:33 PM Dan Ackroyd wrote:
> On Thu, 24 Oct 2019 at 18:21, Ken Stanley wrote:
> >
> > Since PHP 7.0 brought forward the Null Coalescing Operator (??), writing
> > more succinct code for how to handle null values has been a blessing.
> But,
> > what about the inverse when
On Thu, Oct 24, 2019 at 1:46 PM Stephen Reay
wrote:
> Hi Ken,
>
> This sounds like an alternative approach (for solving the same basic
> problem) to the nullsafe operator discussed a while back, no?
> https://wiki.php.net/rfc/nullsafe_calls
>
>
> Cheers
> Stephen
>
Hi Stephen!
Yes, it would be
> On 25 Oct 2019, at 00:33, Dan Ackroyd wrote:
>
>> On Thu, 24 Oct 2019 at 18:21, Ken Stanley wrote:
>>
>> Since PHP 7.0 brought forward the Null Coalescing Operator (??), writing
>> more succinct code for how to handle null values has been a blessing. But,
>> what about the inverse when you
On Thu, 24 Oct 2019 at 18:21, Ken Stanley wrote:
>
> Since PHP 7.0 brought forward the Null Coalescing Operator (??), writing
> more succinct code for how to handle null values has been a blessing. But,
> what about the inverse when you want to do something when a value is not
> null?
Hi Ken,
Since PHP 7.0 brought forward the Null Coalescing Operator (??), writing
more succinct code for how to handle null values has been a blessing. But,
what about the inverse when you want to do something when a value is not
null? You're left with the traditional (and sometimes verbose) methods of
34 matches
Mail list logo
