Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109026 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 12814 invoked from network); 15 Mar 2020 15:26:19 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Mar 2020 15:26:19 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1D8621804E0 for ; Sun, 15 Mar 2020 06:48:27 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, 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-il1-f171.google.com (mail-il1-f171.google.com [209.85.166.171]) (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 06:48:26 -0700 (PDT) Received: by mail-il1-f171.google.com with SMTP id a6so13813508ilc.4 for ; Sun, 15 Mar 2020 06:48: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=ZqxrpBZTf23Wzq2f0y0uNU3phV5K7H2FgVI7rUhdjjY=; b=sv1qOgZ0+3g9p8GqxXv3kMIr0h5ANa39PX7v9PBj5iNR6Z5ztrlsPb1pXZJ3dn8/wh oGQs+CFRGxNPE+CPZ1ie2vS/MuJnrym8/eqgUCE4QjZqwMwpYjPwdYidtqO258ZMHP62 KvTs2h6LG41Is+GHZJMlbYpbrql1w3gxeeav7R3QR0QUK9Lo6XXdGkh3BpCHDnBQSMz0 IS4NgoWQBMyGvj7PZFDja34+f04HPYXbx+4tqxZn+h8BHARSKXsvvxbbmKXzgWFB71MQ tHfQcjE5SP6SQQojzFmU8LZ1Zy4rSl+V27DSS2p1DIYkc8ASrbzTkw1InMquR49q+41m C2mw== 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=ZqxrpBZTf23Wzq2f0y0uNU3phV5K7H2FgVI7rUhdjjY=; b=VH98IjZFIx+BtJnEty9ZB+90bs67U+oYaJBkbefSOGPGXHHSfYIr1lZAbYKWM9UlSh 1yQE36ZxBztZ+0GHI1BtCRfEcZV4qPkVS0TfRYQMOkszPqyoZ/34cvL9hJOwIkwektpu rE/RUJh7zbD9zgLVQnnex9LF/BZmcNT7Ad+pmeZYC/v7PT2+EhBYGsItBkITVQ1N5Eis lm9aiuwkUR2YBwRdug/CVgHPn37X+EnAh3zl2gd0+vuU2N4UOwBo2cPc0tMfMq7rq7YX PTinBUUH6xtPN3fMOIacXyjUssRDBTfuzRY4fYq+9rcYQGGM4tJnDh0QgcmcGlWwXI8Y Rq3g== X-Gm-Message-State: ANhLgQ3c2LIu1gad7BP9QmqyekrMj/20HdI8uYbm6gr9Icz8AzQuRIpA A8Nvay2Qf8O4UM5k2mwFcPa1qbUX31ecg75/dco= X-Google-Smtp-Source: ADFU+vvFAVwJx1q6rccjTWIV8Mm1nz6+sTd6YvP7s22RXeyS9BFzzBBJ9ahbObDFCOPef62llikIAvbsnuarfuHc6e0= X-Received: by 2002:a92:395a:: with SMTP id g87mr20874082ila.35.1584280105092; Sun, 15 Mar 2020 06:48:25 -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> In-Reply-To: Date: Sun, 15 Mar 2020 14:48:12 +0100 Message-ID: To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= Cc: Larry Garfield , php internals Content-Type: multipart/alternative; boundary="000000000000e38e0a05a0e4f48a" Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties From: ocramius@gmail.com (Marco Pivetta) --000000000000e38e0a05a0e4f48a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey M=C3=A1t=C3=A9, On Sun, Mar 15, 2020, 14:04 M=C3=A1t=C3=A9 Kocsis = wrote: > Hi Marco, > > Yes, it still allows default values. > > The reason why I'm reluctant to disallow them is that this restriction > would feel a bit ad-hoc for me. I mean, I wouldn't like to add another > special rule for "write-once" properties, unless there is a strong > argument for it. Besides, as far as I know there is no precedents of > disallowing default values of similar properties in other languages, > so I feel that the feature would stay the most intuitive as it is now. > 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? > However, I'm eager to listen any objections about this. I know for one > that ProxyManager wouldn't work with "write-once" properties having > default values. But can we consider this use-case an edge case, right? > Yeah, that's totally unrelated to library technicalities: since reflection will tell us if a property is write-once, we can work around it regardless. Could users circumvent the issue just by changing the default value > to an assignment in the constructor? Or would it cause a big headache > for them? > I would say that this complicates the semantics more, but you see that the issue is indeed a bit more deep than what we wanted to tackle, so I think a sensible solution is to: 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) We can then use the fact that nobody is relying on them to play with the future scope. Nikic suggested (in chat) an example usage such as default non-scalar values as viable: class Application { public read-only DateTimeImmutable $startupTime =3D new DateTimeImmutab= le (); // ... } --000000000000e38e0a05a0e4f48a--