Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109043 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 98445 invoked from network); 15 Mar 2020 23:22:11 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Mar 2020 23:22:11 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 888261804E2 for ; Sun, 15 Mar 2020 14:44:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,HTML_MESSAGE,LOTS_OF_MONEY,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 15 Mar 2020 14:44:26 -0700 (PDT) Received: by mail-vs1-f42.google.com with SMTP id x82so9930254vsc.12 for ; Sun, 15 Mar 2020 14:44: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=GUtg6VwwFGra0GgxoVLzxSAwwqARDEpS5o2WCb97aPI=; b=KkuzSYIGQf19xuKgaH4zlMChYgs9KAaTAhxMtNfPvfN9pQqAQEakiDf8KUuWzMJL+1 LGMaY5r/3yrIf2NAQ0dD5Mq+PtKWJK83jPpvgk4gIReOmMNYuf/lVgfov9c9jluXieZK /kq2uC3b+NHEPADvtq6YGzBSqNeHHvjLSGZ1ZcaNxeTqpAs7rXlaW22pKWSW5h4Ae/5E /R5HYX7foC3LeUmy3FMr4UBSz4IwjMHvwudsR6aLWPowanJUY9JCeRi8x1wLQMroRQvB 0UPmgWSOTsrYBIoUMhDTOI9r5B3j6GZ0E4HGDJZpv0vAI8FQC0lI4vUgtnYEmoilMz4x xjmw== 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=GUtg6VwwFGra0GgxoVLzxSAwwqARDEpS5o2WCb97aPI=; b=lxkUQ6UwqIRIa2BJkQv2KLe9CaHU5TG65lv/xupoKKZH7QkF64iTSr4qVCZj948QQe 8nSZ7yRJOVVbNpdnY0aURYIqT0Nci3Ad8CEEnPd1HODMSDr7g6YIzvJrtkCMgEqiC5x2 6dhktfapLZ7MwAxV67hRzJ+xd+mon4EbBFt3mAyeKaMqLGeZafvkBC0iFUnzEDPj5wGb Et5rORDL4r16G1A/DgiPDgQo+z0ZFzApls0E8zE7zkmdoLkG2QEwljUR9FIpGJ8JpK3y PSd/kWgpHMpAqwSju8f+4RHHWa6yrdoMH5eWK6kL5qZ6Q1feJ5FJ/ZxHYgvmlPiXUraw W3EQ== X-Gm-Message-State: ANhLgQ3j32MKWTkv5vXkugatqNVL4avLvnDte9yKpLCMOMkBmS2DqG9t AnMrbME2w1V7EuyEP638FE++aZKo7MCl8c+4n+M= X-Google-Smtp-Source: ADFU+vvxzRBaAlbIWSO8mvB2ZnBdYZyTkw9ItHJQoGCXWBaSfPledPS+H2LnVwU4o1KvCei5mCuq9kK5npl8sDYJSdA= X-Received: by 2002:a67:eecb:: with SMTP id o11mr15671452vsp.227.1584308663018; Sun, 15 Mar 2020 14:44:23 -0700 (PDT) MIME-Version: 1.0 References: <8545d15e-ddd5-42be-8405-09697a077234@www.fastmail.com> <4d9688fe-cc57-44af-903e-05f4cbb1bbcc@www.fastmail.com> <6bcbf0a5-92d8-4cfa-a00f-e0e967fc037e@www.fastmail.com> <700327df-45d5-47ca-8828-d7ad9c9bee2e@www.fastmail.com> <6f2e7718-5d78-4c57-8da9-f8dd44cc9e7b@www.fastmail.com> In-Reply-To: <6f2e7718-5d78-4c57-8da9-f8dd44cc9e7b@www.fastmail.com> Date: Sun, 15 Mar 2020 22:44:11 +0100 Message-ID: To: Larry Garfield , Marco Pivetta Cc: php internals Content-Type: multipart/alternative; boundary="00000000000012eb4505a0eb9b6d" Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=) --00000000000012eb4505a0eb9b6d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Avoiding that confusion will save the industry millions of dollars. > On the one hand, you are right, because currently it's not very useful to effectively provide two ways of declaring a constant. On the other hand however, if we also consider a longer term aim of adding support for object default values (just like what Marco mentioned): public read-only DateTimeImmutable $startupTime =3D new DateTimeImmutable()= ; then allowing default values for "write-once" properties seems much more sensible. At this point, the "million dollar mistake" label doesn't hold anymore since class constants and "write-once" properties with default values will actually be two different things. But we've just ended up at Marco's suggestion: > 1. Prevent the parser from accepting default values on write-once > properties (parser error) > 2. Re-introduce them once we know what we want to do with default values > (and it makes sense) > Yes, this scenario definitely makes sense. I'm just not yet sold that it will have any negative effects if we don't restrict the usage of default values now. I understand that it's usually advantageous to be conservative with adding new features - especially when groping in the dark - since we are the ones who have to support and fix them later. That's why I was hesitant to add property covariance to the proposal. But this case seems to be much more well-understood than let's say property covariance would be, it avoids another special rule while aligning nicely with our longer term goals, so I think all in all, it is still a better idea to allow default values than not. I think what will happen is that people will start requesting for read-only > properties with default values to be over-writable-once (a mess): better to remove them from the equation > completely, no? I can also imagine people to ask for default values if we disallow them now. :) After all, we always want what we don't have. ^^ Does anyone else have any more comments or objections? I wouldn't in the least want to be stubborn about this topic, so if anyone has any feelings for/against, it's the best time to reassure my point of view or change my mind. :) Thanks, M=C3=A1t=C3=A9 --00000000000012eb4505a0eb9b6d--