On Mon, Dec 12, 2022 at 10:20 PM Dan Liebner wrote:
> As the RFC points out, "Some languages, such as JavaScript, do not consider
> accesses to undefined array keys to be an error condition at all, and allow
> such an operation to be performed silently."
>
It is by definition an error condition
On 13 December 2022 15:55:41 GMT, Thomas Hruska wrote:
>On 12/13/2022 7:15 AM, Derick Rethans wrote:
>> On Mon, 12 Dec 2022, Thomas Hruska wrote:
>>
>>> On 12/12/2022 3:52 PM, Derick Rethans wrote:
On 12 December 2022 22:20:27 GMT, Dan Liebner wrote:
> It has been proposed to make
> Can you expand a bit on how you think distinguishing "undefined" from
"null" would help?
First off, I would be perfectly happy if undefined array/object index
accesses went back to raising E_NOTICE. Undefined variables already resolve
to NULL so in that sense NULL is already the "undefined" prim
On 13 Dec 2022, at 15:45, Rowan Tommins wrote:
> Although presumably they return null rather than an empty string precisely so
> that users can check if the value was provided, without providing an extra
> method equivalent to isset($_GET['q']), e.g.
>
> [...]
>
> For cases where you don't nee
On 13/12/2022 16:08, Dan Liebner wrote:
Can I also just point out that by current definitions the "null coalescing
operator" isn't properly named, it should be the "undefined/null coalescing
operator". The only reason it is able to get away with not raising an error
for undefined variables is tha
On Tue, Dec 13, 2022, at 10:39 AM, Deleu wrote:
>> And yes, I used to work on a system that didn't do that properly. (TYPO3,
>> ~800,000 LOC) It took me a few weeks, but we still managed to fix all of
>> these issues in mostly one-person-month, mostly with dropping "?? null"
>> around in various
>
> Anyone surprised by any of the changes in recent versions that boil down
> to "know your types and know if you actually have a variable" has been
> living under a rock for the last 20 years. None of this has been a
> secret. The language has been providing more and more tools to
> know-your-t
On Tue, Dec 13, 2022, at 9:55 AM, Thomas Hruska wrote:
> On 12/13/2022 7:15 AM, Derick Rethans wrote:
>> On Mon, 12 Dec 2022, Thomas Hruska wrote:
>>
>>> On 12/12/2022 3:52 PM, Derick Rethans wrote:
On 12 December 2022 22:20:27 GMT, Dan Liebner wrote:
> It has been proposed to make
Can I also just point out that by current definitions the "null coalescing
operator" isn't properly named, it should be the "undefined/null coalescing
operator". The only reason it is able to get away with not raising an error
for undefined variables is that it's described as "syntactic sugar" for
On Tue, Dec 13, 2022 at 4:55 PM Thomas Hruska
wrote:
>
> Not for those of us that run the package managed version of PHP in
> Ubuntu Server LTS it hasn't.
>
> https://wiki.ubuntu.com/Releases
>
> PHP 8.x is brand new as of *next year* from the perspective of those who
> patiently wait for certain
On 12/13/2022 7:15 AM, Derick Rethans wrote:
On Mon, 12 Dec 2022, Thomas Hruska wrote:
On 12/12/2022 3:52 PM, Derick Rethans wrote:
On 12 December 2022 22:20:27 GMT, Dan Liebner wrote:
It has been proposed to make the error level of "Undefined index"
configurable so that teams and individua
On 13/12/2022 14:32, Craig Francis wrote:
Most frameworks return NULL when the user has not provided the value:
$search = $request->input('q'); // Laravel
$search = $request->get('q'); // Symfony
$search = $this->request->getQuery('q'); // CakePHP
$search = $request->getGet('
On 13.12.22 13:53, Dan Liebner wrote:
It breaks my app. Does that count?
This sounds like you completely ignore notices in your application yet
elevate warnings to exceptions/errors. It would be better to log both
notices and warnings without generating exceptions/errors, and look
through those
On 13 Dec 2022, at 12:39, Rowan Tommins wrote:
> On 13/12/2022 10:11, Craig Francis wrote:
>> The null value can come from many sources (e.g. GET/POST/COOKIE/databases)
>
>
> These two examples are interesting in conjunction: $_GET, $_POST, and
> $_COOKIE will never contain null values unless y
On Mon, 12 Dec 2022, Thomas Hruska wrote:
> On 12/12/2022 3:52 PM, Derick Rethans wrote:
> > On 12 December 2022 22:20:27 GMT, Dan Liebner wrote:
> >
> > > It has been proposed to make the error level of "Undefined index"
> > > configurable so that teams and individual developers can decide
>
On Mon, 12 Dec 2022, Rowan Tommins wrote:
> On 12 December 2022 22:20:27 GMT, Dan Liebner wrote:
> >Here's my biggest criticism: the change essentially forces this:
> >$arr['key']
> >
> >to be rewritten as this (or some other intolerably bad alternative):
> >isset($arr) && isset($arr['key']) && $
On 13/12/2022 12:53, Dan Liebner wrote:
It breaks my app. Does that count?
The only way a Warning can break an application is if you're running a
custom handler which promotes it to an error. If that is your case, then
blaming PHP is a little bit like programming your car to do an emergency
> No, code doesn't break. It now shows a warning instead of an error. There
is no behavioural change.
It breaks my app. Does that count? And didn't you follow up by referencing
this as "adding settings that change behaviour"? Does it change behavior or
not?
> Adding a configuration setting to make
On 13/12/2022 10:11, Craig Francis wrote:
undefined indexes are a classic, but once you've found them all (the tricky
bit), it often makes your code better, and helps identify mistakes (similar to
undefined variables).
[...]
The null value can come from many sources (e.g. GET/POST/COOKIE/databa
On Tue, Dec 13, 2022 at 11:16 AM Andreas Leathley wrote:
>
> On 13.12.22 11:01, Robert Landers wrote:
> > intended: ($a['foo'] ?? null) || ($a['bar'] ?? null)
> > Further, writing code like this increases the number of opcodes needed
> > to perform relatively simple logic by ~150%, increasing end-
On 13.12.22 11:01, Robert Landers wrote:
intended: ($a['foo'] ?? null) || ($a['bar'] ?? null)
Further, writing code like this increases the number of opcodes needed
to perform relatively simple logic by ~150%, increasing end-user
latency and spending CPU cycles somewhat needlessly.
I think it is
On 12 Dec 2022, at 23:36, Thomas Hruska wrote:
> I suspect many people are in a similar holding pattern who are currently
> running packaged 7.4.x and are just now discovering all of the changes for
> PHP 8.x as they are planning out their system upgrade paths in the coming
> months. While you
On Tue, Dec 13, 2022 at 12:36 AM Thomas Hruska wrote:
>
> On 12/12/2022 3:52 PM, Derick Rethans wrote:
> > On 12 December 2022 22:20:27 GMT, Dan Liebner wrote:
> >
> >> It has been proposed to make the error level of "Undefined index"
> >> configurable so that teams and individual developers can
On 12/12/2022 3:52 PM, Derick Rethans wrote:
On 12 December 2022 22:20:27 GMT, Dan Liebner wrote:
It has been proposed to make the error level of "Undefined index"
configurable so that teams and individual developers can decide for
themselves how they want this situation to be handled. Given t
On 12 December 2022 22:20:27 GMT, Dan Liebner wrote:
>Here's my biggest criticism: the change essentially forces this:
>$arr['key']
>
>to be rewritten as this (or some other intolerably bad alternative):
>isset($arr) && isset($arr['key']) && $arr['key']
Fortunately, this is not the case, the act
On 12 December 2022 22:20:27 GMT, Dan Liebner wrote:
>It has been proposed to make the error level of "Undefined index"
>configurable so that teams and individual developers can decide for
>themselves how they want this situation to be handled. Given that:
>
> - PHP has been treating this as an
26 matches
Mail list logo
