Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119465 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 67862 invoked from network); 4 Feb 2023 00:22:29 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 4 Feb 2023 00:22:29 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 5BC3618037E for ; Fri, 3 Feb 2023 16:22:28 -0800 (PST) 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, T_SCC_BODY_TEXT_LINE 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-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 3 Feb 2023 16:22:27 -0800 (PST) Received: by mail-vs1-f52.google.com with SMTP id 187so7113936vsv.10 for ; Fri, 03 Feb 2023 16:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XdefTUnr5YxvhPoKuTuqoHC3WgTglBVIWch2zGljtck=; b=ACkiJlmpbfI1a8Gjqv/8Xi4xv6/9tQCTnLOaGncK9X75pFQKfdmorZLyeDqogcyhQQ yRHpIUA+s7JSxRgeVyLGFdu86PjdLi7fFDsF/SJrnvSRBzvaEeISkFm6xhUPyjQShaMg 8oV39gpP45UVyGAeNLGHbr/hlh5m5oY5k4ONfg6lRgly7GtEp1ZeGmSs9u8BADJO0yiC CFt3kmkj2wCKbCSVEoE3HK8vaUIISNPNjo/Eg7GmAJ9rPxWYC7cIHpcTe2fUHAfd1t9O nVw3fOJ0qscQKzVkChd2q6SrBWJljrw05weEAASSHY3nogkjd43aYcwK5RECaowHSoZQ GOyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XdefTUnr5YxvhPoKuTuqoHC3WgTglBVIWch2zGljtck=; b=j/k1S8cKchhUjspEZqdedG5se4ZCD6U2M2l/Fn1xEAoZ/wZz+gJoBm2UFRHhVljsJp TbhYQagJzLLuZ30YLMRIcCzvp+LrWBshUAITSdOdPZLDRwdEvRA39RMnCZt5rkCXMHt2 JkaM8Th0MyThRA+JjVpOeaxoBXmsXrVkYY0kNvOQg0zYXa+dXDmhAlKfxzqWRRBUZtSD 4c65ByovkAW5t7drEI3dbIOlNobGxpEZKXeRHbhbSVy/CysLn3Alt31+GCCsxa7F3CDY 3bDRKOnWy8aAI9YjTSpBt17ACuXns+SwiDoheegXVuHApAPXWp02XgU0R/CQcAX9/mvB lVOw== X-Gm-Message-State: AO0yUKWjyrZyYEUYLOyGGT4d7dGuNNP959jPqcmOdQ19wAZEhphf0Ngv 6dqPNYkWFKdzWCvMxTlyPUz9q8Mvz0YpVDguZ7Y= X-Google-Smtp-Source: AK7set8Fs+irvZXIayoVaDaegPHDJDatwrzc6k3Y8xIz5hfYxC4TE6Te56+Weg9JUy6ogKQZADQpeGXDoCIrWI2qJ0Y= X-Received: by 2002:a67:f358:0:b0:3f6:e076:f90f with SMTP id p24-20020a67f358000000b003f6e076f90fmr2258335vsm.20.1675470147005; Fri, 03 Feb 2023 16:22:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 3 Feb 2023 17:22:15 -0700 Message-ID: To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= Cc: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= , PHP Internals List Content-Type: multipart/alternative; boundary="000000000000f1b36905f3d4cae6" Subject: Re: [PHP-DEV] [RFC] [Discussion] Typed class constants From: mbniebergall@gmail.com (Mark Niebergall) --000000000000f1b36905f3d4cae6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable M=C3=A1t=C3=A9, Benas, Internals, On Fri, Feb 3, 2023 at 7:34 AM M=C3=A1t=C3=A9 Kocsis wrote: > Hi Alexandru, Mark, > > > > 1. Why is object type not supported? I can't see a real reason and also > > there is no explanation why. > > > > Sorry for this, mentioning object as unsupported was an artifact from the > original version of the RFC which > was created back then when constants couldn't be objects. After your > comments, I removed the object type > from the list. Thank you for catching this issue! > > > > 2. In the examples for illegal values, it would be good to explain why > > they are not legal. > > I don't understand why "public const ?Foo M =3D null;" wouldn't be le= gal. > > I think "?Foo" should work the same as "Foo|null" that would be legal= . > > > > It was there due to the same reason as above. I removed this example no= w. > > I had updated the RFC page, but it looks like the changes were reverted i= n > > December 2022. The updated version I was working on was: > > https://wiki.php.net/rfc/typed_class_constants?rev=3D1648644637 > > > Yeah, the original author of the RFC was surprised to find your changes i= n > his RFC (https://github.com/php/php-src/pull/5815#issuecomment-1356049048 > ), > so he restored his original version. > Next time, please either consult with the author of an RFC if you intend = to > modify the wording, or you can simply create a brand new RFC - even if it= 's > very similar to the original one (just don't > forget to add proper references). > See https://externals.io/message/117406#117460 about contact attempts that were made (with no response), and other discussions about why I used the existing RFC instead of creating a new one. Next time I will just start a new RFC if an author is non-responsive. This is also a bigger policy question for other seemingly-abandoned RFCs. If it is agreed that a new RFC should be created in this scenario, I will update https://wiki.php.net/rfc/howto since that scenario is not specifically covered. That being said, the RFC was discussed publicly actively last year, and the RFC was revised based on the public input. With the reverting, valuable community input was dismissed. An effort should be made to address applicable previous community input instead of just reverting it out. I will work on a new RFC to follow this implementation to introduce inheritance. > > The updated RFC looks good, thanks for working on it. You may want to > > review the revised version I had worked on for implementation ideas, an= d > > review the previous conversations. > > > > I also saw your proposal, but to be honest, I'm not that fond of the idea= . > This doesn't mean though that you shouldn't create a new RFC or an > implementation, as others may find it useful. If you kick off > the project, I'll surely try to review your work. > That is fine to break it apart as a future RFC. I have seen too many real world use cases where inheritance with typed constants would solve problems. See https://externals.io/message/117406#117408 for an explanation. Adding typed constants independently adds value, so it should progress. > > Regards, > M=C3=A1t=C3=A9 Kocsis > Overall, I'm happy to see that this is progressing again, thanks for working on it. - Mark Niebergall --000000000000f1b36905f3d4cae6--