On 26/01/2022 14:48, Christian Schneider wrote:
Please don't flame me, I just wanted to point out that there is an opposing
view on internals to consider ;-)
It is my firm believe that a language such as PHP should not be
dependent on static analysers to protect users against engine-level
On 26/01/2022 17:13, Rowan Tommins wrote:
For instance, the following code is safe, useful, and readable:
$countsByDayByCategory = [];
foreach ( $someData as $item ) {
$countsByDayByCategory[ $item['day'] ][ $item['category'] ]++;
}
I myself am not planning to hold a vote on undefined
On Wed, Jan 26, 2022 at 5:35 PM Christian Schneider
wrote:
> My experience is quite the opposite: Systems will stay on older PHP
> versions for much longer so they do not having to deal with the work.
> Especially for shared hosting services.
> Which is even worse in my books.
Projects that
Am 26.01.2022 um 17:42 schrieb Craig Francis :
> While I did begin an RFC to allow *some* functions to be more tolerant of
> NULL, especially for those scripts not using `strict_types`:
>
> https://wiki.php.net/rfc/allow_null
>
> Or in other words, to "relax certain type requirements on a case
On 26/01/2022 14:48, Christian Schneider wrote:
2) Hot take: I still consider the well-defined constructs like $count++ or
$counts[$word]++ to be useful
I agree, particularly with regards array items rather than top-level
variables. Last time this came up, I suggested that before promoting
On Mon, 24 Jan 2022 at 23:47, Mark Randall wrote:
> Let's open a discussion as to what we might want to do in the future,
> and depending on how things shake out, we can decide what route to take
> with regards to bringing RFCs to vote.
>
While I did begin an RFC to allow *some* functions to
Am 26.01.2022 um 16:55 schrieb Lynn :
> I don't want to waste time trying to figure out if an undefined `$j++` is a
> bug because it should've been `$i++`, or that `$i = 0;` is supposed to be
> unused because someone forgot to remove it. Given the legacy I work with,
> it's unrealistic to have
On Wed, Jan 26, 2022 at 3:48 PM Christian Schneider
wrote:
> I do not think we should make undefined variables (and array indices?) an
> error:
1) Static analysis has gotten a lot better and catches most of this, often
> even earlier than the runtime check.
> 2) Hot take: I still consider the
On Tue, Jan 25, 2022 at 5:11 PM Rowan Tommins
wrote:
> On 25/01/2022 19:44, Chase Peeler wrote:
> > If we start throwing exceptions, which can't be suppressed, it will make
> > this much more difficult to read since the constants.php will have to be
> > updated:
> >
> > if(!defined('dbserver')){
Am 25.01.2022 um 00:47 schrieb Mark Randall :
> ** Undefined Variables Promoted to Error **
>
> PHP currently treats reading an undefined variable as though it were a null,
> emitting a warning message in the process. This was previously promoted from
> a notice in the PHP 8 engine warnings
Hey Jakub,
On Wed, Jan 26, 2022 at 1:58 PM Jakub Zelenka wrote:
> >
> > PHP 9.0, likely a few years away at this point, is our next opportunity
> > to make significant breaking changes.
> >
>
> Maybe we should give users a bit more time for adoption and consider major
> version bump when PHP 8
>
> PHP 9.0, likely a few years away at this point, is our next opportunity
> to make significant breaking changes.
>
Maybe we should give users a bit more time for adoption and consider major
version bump when PHP 8 has got at least 80% and the PHP 5 usage is close
to zero. I know that it's hard
12 matches
Mail list logo
