Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106996 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 13680 invoked from network); 12 Sep 2019 20:31:37 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 12 Sep 2019 20:31:37 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id A4D4E2D2001 for ; Thu, 12 Sep 2019 11:07:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Virus: No Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Thu, 12 Sep 2019 11:07:34 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id f25so8314495uap.1 for ; Thu, 12 Sep 2019 11:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OfDKm9INPt0ESSnN+0GzcSG+a6o6DymhEwgp2coyj+E=; b=gzdXVUetTp1WzYM4g5eA+vaM4B+kDzydPLUjAz74viOamARIVV1sXzLIjqCLQzlC7c axLpzsA1yad+tCKg/WYtYhjfIsLGW68ng0vOZGP58yxLJt2dVsV4Szt35+a95uD6MPdP 4o4Bagm/E10nK6IhU7G5AglffsIlYntM/X2bvb0uASG8DVit5Nqy8sKf4T9p1sK2Lt42 +rzfbxVIzoSjFL+9+iSrgTcdm5Fz7V9jJp3OZ0oQSuCMJVRHNZPomuejXWUJ7Z4jJqOT IbeM+6CBaEyqbAuEroKRdH4Bj3kvp10s36CuIeri/Qtsz6qezaEVeRcPMYmcsHk1UmQa g2Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OfDKm9INPt0ESSnN+0GzcSG+a6o6DymhEwgp2coyj+E=; b=DGE5n8qtbQj0JtbJAp7mP1J2ZwzM+ELugK6YS/uQ7TZJly9D4DkIQBecQy6r168UxU E8I+XvlJNyqqQwMH7+IejAC8FmdaKLBBv2druUgGhJBG3ac2nCrqgemcdPrrbqMj9haI RRK86AMcRIbG3tlTMRjaXn4weIcHN+cP9hEt0XVgWnCkLoArd6LNxRGAya4Z6xdxV8rs rVvvEC5gKHjg5itobIJJ7YA+JzNs1jjBczRp0creFYWN5iRsfZYmeRNq+ltPj9T3WrDl uXdoAFAqw1n4ur48QdWZuO9SPUhi6BUhnOzDaN1SEN2+jLd9YdlF2oETeYcq/4Tb8UW6 41Ig== X-Gm-Message-State: APjAAAVy4KuRuMG08zqaMzjy/VJI/WJ9FjMgVy1+yiNA6FFVX7VsYgJP hDZeeDfxGsbBLJ0sIVCAk9oRa4tk16NoVZ33sHo= X-Google-Smtp-Source: APXvYqxdta+++p6XppJT16nl61erwmSry3cEhHLAlcrlNBhfADi8SvMH05lfXbynqv871G/OPKVNd+2pwTc9v6rsZ0A= X-Received: by 2002:ab0:5b1d:: with SMTP id u29mr18494940uae.38.1568311653831; Thu, 12 Sep 2019 11:07:33 -0700 (PDT) MIME-Version: 1.0 References: <076701d56978$86020910$92061b30$@php.net> <078e01d5697c$5512bc10$ff383430$@php.net> <262D6749-66C3-4544-9FA0-32CDA6EC402A@koalephant.com> In-Reply-To: <262D6749-66C3-4544-9FA0-32CDA6EC402A@koalephant.com> Date: Thu, 12 Sep 2019 14:07:22 -0400 Message-ID: To: Stephen Reay Cc: Matthew Brown , Scott Arciszewski , Zeev Suraski , Marco Pivetta , PHP Internals List Content-Type: multipart/alternative; boundary="000000000000061abc05925f0391" X-Envelope-From: Subject: Re: [PHP-DEV] Changing fundamental language behaviors From: chasepeeler@gmail.com (Chase Peeler) --000000000000061abc05925f0391 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 12, 2019 at 1:58 PM Stephen Reay wrote: > > > On 13 Sep 2019, at 00:41, Chase Peeler wrote: > > > > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown > > wrote: > > > >> What if Java suddenly said that all properties are suddenly private, and > >>> can only be accessed through getter/setter methods? > >>> > >> > >> If Java announced that the next major version was to make the change > after > >> 95% of userland developers favoured it and over 2/3rds of their > internals > >> team did, I'd think "huh ok I guess they have good reasons". > >> > >> For 20 years people have developed code based on that feature. It was > >>> never considered an error, and often not even considered bad practice > >> > >> > >> You seem to be arguing against *ever* changing something that a majority > >> once thought was good, and fundamental to a given system. Lots of things > >> fall into that category - restricting voting to men, segregation, etc. > >> > > > > Now you're just being silly. I actually don't have a problem with > > fundamental language change, provided that the positives that are gained > > far outweigh the negatives of the BC break and there is no other way to > > accomplish those positives without such a BC break. > > > > There are a myriad of ways to achieve what the RFC attempts to achieve. > > Whether that's analysis tools, custom error handlers, detailed code > > reviews, etc. Nothing prevents anyone from initializing all of their > > variables or performing as many sanity checks on a variable before > > accessing it as they want to. Nothing in the RFC is required to implement > > other new functionality like enums, union types, variable typing, etc. > > > > I also think it's a bit of a stretch to compare something like variable > > initialization with things that denied people their basic human rights. > > > > -- > > Chase Peeler > > chasepeeler@gmail.com > > > Please, will someone arguing against making use of undefined variables a > higher severity, explain to me why the same argument was not made for use > of undefined constants, for which the RFC to deprecate/remove support, > passed 41:0. > > How is one undefined symbol more acceptable than another undefined symbol? First of all, I wasn't as involved with this list back then as I was now. However, I can see a fundamental difference in the two. Not needing to initialize variables just for the sake of initializing them (e.g. just doing $i++ without $i=0 before it) is something that is going to behave as expected almost all of the time. When it doesn't, you can easily initialize $i to a non-zero value, or, you can initialize it to zero if you want - it doesn't hurt anything. An undefined constant getting converted to a string, though, is much less likely to be the intended behavior. String literals are required to be in quotes. Constants can never be in quotes. Assuming that the token that looks like a constant, but can't be because the constant didn't exist, so, we'll pretend it's a string even though it doesn't match the proper syntax for such a token is drastically different than assuming the variable you are incrementing that wasn't initialized is 0, or, that the variable you are concatenating to, but wasn't initialized, is an empty string. Finally, let's pretend that the undefined constants RFC was a horrible RFC that shouldn't have passed. The fact that it did has no impact on whether or not this RFC should pass. -- Chase Peeler chasepeeler@gmail.com --000000000000061abc05925f0391--