Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119469 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 1828 invoked from network); 5 Feb 2023 16:29:48 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 5 Feb 2023 16:29:48 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 31A181804AC for ; Sun, 5 Feb 2023 08:29:46 -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, 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-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (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 ; Sun, 5 Feb 2023 08:29:42 -0800 (PST) Received: by mail-lj1-f179.google.com with SMTP id u27so9872369ljo.12 for ; Sun, 05 Feb 2023 08:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gi20q3AHnzYdAXWA3F1fbN+Latgwhi28/1kS4fXaEZw=; b=Z5wYLfESRFJA0eUPcly9lEUReiAELahidr3WOCa5tqFARUWymZg9GjPwboFILTaPFk XdH+Es5orV12ep99LBMy9aW0erCHoEteyZalyPDUQ2fSupJg4tRNdlN0TjRcFTfljAlV Z40W/QQry4Xnsv2+tn2Zza+i05V9ow6f140B+BUnB2feYDT6Rk0LXBbQvDo7k5epGsgv Hoz3xt43cQTtppIDsoQ/UrhuSNq+MYGrnOXqp127cOoTSRfDxTpn6ZdvaT1rsB9CuBK/ EwbtTkDhdx6egmuHONZMcP9hoTFFZ3VhS8WU/cgab+Nal3mwjWgbIP51aI1rilr1++8N T/Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=gi20q3AHnzYdAXWA3F1fbN+Latgwhi28/1kS4fXaEZw=; b=byL9FWD2inMDXpVLn5syCYSWAwbx0iqSR9lmkUeaKZ/BdbfBgyZm5r4yW8To+8wRWj m9XiAQjGTix7CHGRCTdcRW647AYgdvE6oc3CJGbab1clWO4iubAtI7qCbkG3BrS3UT9k 2qZbxIz4r0IJIfztfHSXd+NyCxr2pFozWnxCmBB5gG0B0pFbp5u1WHdm/zi2RLoxC5j1 8PpBm3zEk330DkvgZXM/83V8ZDUkG9js0kUt3e4J955Y6Y1IDY/siU7t1AcDNfYVY/ss hsXPEjwuaYEFH5mHyDI2xAOcJxdlsQ/N0xC8Ve2ABt/rI94BEUg9HhphMD0jxtnAow51 mwdw== X-Gm-Message-State: AO0yUKVqq/neUcgexEnC19/HK9Xw2sXfnU2RpdVBQ8UyV/ef0EGRJBAA 2+i2RG1bALuSBRfn13NcsK8TdTpvs+9E8jEUSO4= X-Google-Smtp-Source: AK7set8zGdeoygTadst9NbJOumvpCoLka77OiE/oVOPKmLIRXBolpnGcKw2BH1TapdQTnDPdsiCTRLrvCDyvhgpiopM= X-Received: by 2002:a2e:958b:0:b0:290:67a6:38d2 with SMTP id w11-20020a2e958b000000b0029067a638d2mr2495762ljh.184.1675614580962; Sun, 05 Feb 2023 08:29:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Sun, 5 Feb 2023 18:29:29 +0200 Message-ID: To: Mark Niebergall Cc: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= , =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= , PHP Internals List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] [Discussion] Typed class constants From: benas.molis.iml@gmail.com (Benas IML) [copy of the email that I have accidentally sent to Mark individually] Hey, As much as I appreciate your enthusiasm and ideas, adding your name on my original RFC and editing its contents without my approval is not acceptable. Especially considering that contents of the RFCs are a direct representation of my stance and views on a particular feature. As such, I would not like to have my name put on proposals that I have never discussed nor proposed myself. In this case, I explicitly have given M=C3=A1t=C3=A9 permission to continue working on this RFC and in taki= ng it under his wing. That being said, feel free to open a new RFC yourself and copy the contents of your previous proposal from the wiki's history tab. Best regards, Benas P.S.: Next time, try also contacting me over Room 11 or GitHub, given that I rarely check this email. On Sat, 4 Feb 2023 at 02:22, Mark Niebergall wrote= : > > 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 al= so > > > there is no explanation why. > > > > > > > Sorry for this, mentioning object as unsupported was an artifact from t= he > > 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 wh= y > > > they are not legal. > > > I don't understand why "public const ?Foo M =3D null;" wouldn't be = legal. > > > I think "?Foo" should work the same as "Foo|null" that would be leg= al. > > > > > > It was there due to the same reason as above. I removed this example = now. > > > > I had updated the RFC page, but it looks like the changes were reverted= in > > > 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= in > > his RFC (https://github.com/php/php-src/pull/5815#issuecomment-13560490= 48 > > ), > > so he restored his original version. > > Next time, please either consult with the author of an RFC if you inten= d 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 tha= t > 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 R= FC > 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 t= he > 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, = and > > > review the previous conversations. > > > > > > > I also saw your proposal, but to be honest, I'm not that fond of the id= ea. > > 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 shoul= d > 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