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
The PHP development team announces the immediate availability of PHP
7.1.33. This is a security release.
All PHP 7.1 users are encouraged to upgrade to this version.
For source downloads of PHP 7.1.33 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The
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 Oct 24, 2019, at 12:31 PM, Rowan Tommins wrote:
>
> On Thu, 24 Oct 2019 at 16:38, Mike Schinkel wrote:
>
>>> Here, try() would swallow only FileException, other exceptions are still
>>> thrown. I'm not sure if this construct is worth introducing though, the
>>> difference compared to a
> On Oct 24, 2019, at 8:50 AM, Dik Takken wrote:
> However, you could also choose to leverage the new behavior of throwing
> exceptions to simplify your code. Passing the error condition to the
> caller can now be done by *not* handling the exception that is thrown, so:
>
> $filepath = __DIR__
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
On Thu, 24 Oct 2019 at 16:38, Mike Schinkel wrote:
> > Here, try() would swallow only FileException, other exceptions are still
> > thrown. I'm not sure if this construct is worth introducing though, the
> > difference compared to a proper try / catch is much smaller.
>
> I would want it to
> On Oct 24, 2019, at 8:05 AM, Dik Takken wrote:
> I fully agree. However I think the fear of having to add tons of try /
> catch to existing code is exaggerated. I use Python a lot, which
> quite an exception throwing machine in comparison. Still, my code is not
> cluttered with exception
On 24/10/2019 13:47, Rowan Tommins wrote:
The simpler idea I had in this area was caching what type checks a value
had passed, either on each zval or perhaps just at the class level, so that
checking the same type again would be much faster, even if it was a complex
union with multiple
On 21-10-19 19:56, Mike Schinkel wrote:
> The idea that functions that I could previously dealt with in four lines of
> code:
> $filepath = __DIR__ . '/foobar.json';
> if (false === ($content = file_get_contents($filepath)) ) {
>error_log( sprintf("failed to open '%s'", $filepath ));
>
Hi Dmitry,
On Wed, 23 Oct 2019 at 16:43, Dmitry Stogov wrote:
> Actually, I think PHP already took wrong direction implementing "typed
> references" and "type variance".
> Introducing more "typing", we suggest using it, but this "typing" comes
> with a huge cost of run-time checks.
> From 10%
On 21-10-19 19:19, Mark Randall wrote:
> On 21/10/2019 17:02, Rowan Tommins wrote:
>> - They immediately jump control out of the current frame of execution.
>> Unless you put a separate "try-catch" around every line, there is no
>> "acknowledge and run next line".
>
> I've been toying with the
On 21-10-19 18:02, Rowan Tommins wrote:
> There is no general way to know whether the result of aborting execution
> completely is better or worse than carrying on with unexpected values. In a
> program that's not expecting it, either one could lead to data loss or
> corruption.
I would guess
Hi,
The PHP development team announces the immediate availability of PHP
7.2.24. This is a security release which also contains several minor bug
fixes.
All PHP 7.2 users are encouraged to upgrade to this version.
For source downloads of PHP 7.2.24 please visit our downloads page.
Windows
The PHP development team announces the immediate availability of PHP
7.3.11. This is a security release which also contains several bug fixes.
All PHP 7.3 users are encouraged to upgrade to this version.
For source downloads of PHP 7.3.11 please visit our downloads page.
Windows binaries can be
Hi all,
I've closed the vote. Object Initializer RFC failed with 26 votes against
and only 3 in favour.
The second vote has a meaning only for future revive of this feature.
The majority decided that the preferred assign token should be eq "=".
Thanks to all for taking a vote.
Cheers,
Michał
38 matches
Mail list logo
