Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107008 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 39547 invoked from network); 12 Sep 2019 21:28:29 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 12 Sep 2019 21:28:29 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 1B79A2C101D for ; Thu, 12 Sep 2019 12:04:27 -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-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 12:04:26 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id p13so1745941vsr.4 for ; Thu, 12 Sep 2019 12:04:26 -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=mhPHsAcJyZRQO7GxTkr+tesPicl7edS+6RLOzade/eI=; b=lwcLwl5MziUzL0E9ouJUf7iqWy+8iugAioCfonU1Rtrj+ftGMNKo//wTcAd4AGKa2L J2nqHIAP8y7HxmodPJAVbXa91Cl+eMQiVdeH4R8f363fTmZQRPvhj3VECRvZ7n8D+WtD CuNvrmqORHTV/5PQHmJtXIx1rfkP88KKr0bbAEFSSUvSgcIHBf43ifsHFcIx/RMwZDw+ e7s4ucWeDfRptJBoYn+utu/csS+W0V3C1II9xuzo+NQfupT4mmUXo2u+ME5WQ7iU3wGb dT8yCqzGIIkK1tGHEfWde2IcbqWUTJr8SOXdUHa6lLSEkDcn/0WSlBUOVQR2GPzu6K8c OiCw== 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=mhPHsAcJyZRQO7GxTkr+tesPicl7edS+6RLOzade/eI=; b=s2wrnQULlFF8IYeteHsDRgbZfIGirYhp+7YFMqN0dZtCADWVJROlNY98qT+yAuPwk1 V1HLFPOhNhP70MvGybDVmkIbzdgpi73GOVmkX+XbEGTqBJlFzXXGYHsDaGfLUwgwGxnc 1W3j8RVCjDEhZdfIQImm5LNzLCe8c1WYhCvTjnu9RqRTc7XaI4MCfwZOdxgHa4kiA9Xj N3+nlLwDWrEb4VVYYIygmE1DQY0MM3qioOUOPvh9LaKE3zPm0/AfcOngktuEFI4PR8ax wAQTemoYdS9qYC3mq3hKFgDnZrsFMDcr4zcpH06D0++KG6qiWE7ryfw7ZN8mEHCkidV3 kLVQ== X-Gm-Message-State: APjAAAVl7l0zbe/UqbwQs+Zl9MhWh+cfZ7lv7WOLUqbwt+q2vQWTNNEw U2YnMC0I0nL0W/RZ/lHQtnACET3oN+osCymBzIM= X-Google-Smtp-Source: APXvYqyukUHKyShcB49vcLaXupFzUdoHVPL9Dgw+W+JHPgey/MArlk5ttIpuyzpqIp3F3WyWpIQ3Mw16ygWZuIWbZo0= X-Received: by 2002:a67:ec14:: with SMTP id d20mr24214490vso.209.1568315065853; Thu, 12 Sep 2019 12:04:25 -0700 (PDT) MIME-Version: 1.0 References: <076701d56978$86020910$92061b30$@php.net> <467be4a0-dd8b-29d2-0b09-a3efd7fad56a@heigl.org> In-Reply-To: Date: Thu, 12 Sep 2019 15:04:14 -0400 Message-ID: To: Peter Kokot Cc: Zeev Suraski , Andreas Heigl , Internals Content-Type: multipart/alternative; boundary="000000000000656c2005925fcebb" X-Envelope-From: Subject: Re: [PHP-DEV] Changing fundamental language behaviors From: chasepeeler@gmail.com (Chase Peeler) --000000000000656c2005925fcebb Content-Type: text/plain; charset="UTF-8" On Thu, Sep 12, 2019 at 2:51 PM Peter Kokot wrote: > On Thu, 12 Sep 2019 at 20:35, Zeev Suraski wrote: > > > > On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl wrote: > > > > > > > > > > > > You may be wondering, in that case, what processes do we have to deal > > > with > > > > such changes then? The answer is simple. We don't. We don't have > to > > > have > > > > them either - the fundamental language behaviors are here to stay. > > > > > > But we still need processes to define which are the "fundamental > > > language behaviours". And as change is the only constant in > > > software-development, these "fundamental language behaviours" might, > can > > > and probably should be changeable. I'm not saying they need to change, > > > but it has to be possible to change them. Otherwise we would still > > > program business-logic in C as that was Rasmus' fundamental idea IIRC > > > (Correct me if I'm wrong) > > > > > > > You're right. The thing is this - as I said, the RFC process was > designed > > to address additions to the language - as is implied in numerous places > > (both the part I quoted from the RFC itself, as well as elements in RFC > > template as well as the RFC howto). It was never meant to handle > > deprecations - mainly because we simply weren't doing much of that back > in > > the days where it was introduced. It was meant to resolve the issue at > > hand at the time (and in the years leading up to it) - which is a formal > > way to agree on which features make it in and which ones don't. > > Now, over the years (and more and more as of late) - it started being > used > > for deprecations. But these deprecations have become more and more > extreme > > recently in terms of their impact. Of course I do think deprecations > > should be allowed, like in any other language. I do think we need to > have > > a higher bar for them in general (both in terms of a clear benefits and > > required majority - as is implied in the Voting RFC) - but since we've > > grown used to using 2/3 for them - and given the pro-deprecation bias of > > the current composition of internals@ - I also realize it will be tough > to > > do. But when dealing with deprecation proposals that are likely to > effect > > a very sizable subset of our userbase and codebase, and deal with some of > > the most basic building blocks of the language - we simply can't start > > using the same process. We never have in the past (none of the > > deprecations we voted on since 2013 comes even remotely close to the > level > > of impact of the two proposals that have been put forward to a vote in > the > > recent couple of months, and the more recent one clearly far outdoes the > > prior one in terms of impact). > > > > Should we have 'woken up' many years ago when we started using the Voting > > RFC for deprecations it wasn't meant to handle? Probably. It would have > > been much easier to install a new mechanism. But it doesn't mean we > should > > repeat the same mistake, now that it begins to be used to deprecate > > mainstream language behaviors. > > > > In terms of telling one from the other - right now, I'm afraid it's a bit > > like some other things that fall into the category of 'you know it when > you > > see it'. I think few can deny that far-reaching effect of changing how > > variables behave in a language, whether they think it's a change for the > > better or for the worse. But I think it *may* be possible to formally > > define. These are just random thoughts at this point - but we could > have a > > set of apps/frameworks that we use as a testing bed to check the level of > > impact of a certain proposal. If that impact is above a certain > threshold > > - it will be considered fundamental. Of course, things like WordPress, > > Joomla and MediaWiki would have to be a part of that - not just modern > > frameworks. It's still not ideal since it doesn't account for the > majority > > of PHP code out there which isn't Open Source - but it may be a start. > > There may be other ways - such as letting folks run that analysis on > their > > own code behind the firewall and report results back. > > > > But there's also a simpler solution to this. This 'can of worms' as > Arvids > > called it, wouldn't have been opened had we agreed to focus on extending > > PHP instead of trying to replace it with something else. This is what > the > > RFC process was meant to facilitate. It still can, but for that, we need > > to change the dynamics from a zero-sum game to a goal of a win/win. > Yes, I > > realize that I'm sounding like a broken record. But call me naive - I'm > > still hoping that given it obviously can be done from a technical > > perspective (in a wide variety of ways too) - we can find the good will > to > > do it from a human perspective. > > > > Zeev > > > > > > > > > Just a dumb idea, since there clearly is a majority in favor of the > change with these warnings and strictness and all that now... Why not > making something like an LTS PHP 7.x where all the legacy code would > work OK as long as practically possible and 8.x+ would be the future > of what the developers want and not what business wants? One who won't > upgrade due to the BC breaks also won't need the new features anyway > very realistically. > > Someone that has a lot of uninitialized variables could definitely take advantage of features like enums and union types (just to name a few). If there were actually new, useful features that were dependent on such a change, then I'd be much more open to the idea, if not outright in favor of it. However, there aren't any new and useful features that are dependent on the errors being thrown for uninitialized variables. > Microsoft, Zend, and Red Hat have been showing that this is actually > possible. How smart this is for the PHP progress is another story, but > for the business it might be good to think about this also I guess: > https://github.com/microsoft/php-src/releases > > So, to make some sort of a milestone with some of the versions - > either 8 or 9 or something. > > > -- > Peter Kokot > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Chase Peeler chasepeeler@gmail.com --000000000000656c2005925fcebb--