Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117422 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 32034 invoked from network); 24 Mar 2022 17:50:40 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Mar 2022 17:50:40 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1679E1804C3 for ; Thu, 24 Mar 2022 12:17:43 -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_H3,RCVD_IN_MSPIKE_WL,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-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) (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 ; Thu, 24 Mar 2022 12:17:42 -0700 (PDT) Received: by mail-ej1-f49.google.com with SMTP id qx21so11103075ejb.13 for ; Thu, 24 Mar 2022 12:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+LdWOs6V7Uzy6Z9b9wmGwQ/MOW781RtAN59OBClMvJM=; b=b6Wpr0b0/7Q6w+kae/k0enOcWBUl29DFIfBhuFXmbaM0aBvLtgJfLZGyJoixUbuDGX xzBRKntXxnt/OMAAZA/xpzWQPuu2Nvk5ySBmNqmK8WDNgoWSPTpihVJNeC3SgZXPidht dqR0RVuCkbm7I0IC9DsJa6ylGubkIG88OYq/uBciiRnWCul+FQQReagrf0syBrM+q0F/ bPwcs/zlGTgb0r4mU/I4KppwQFETtkIca1o9iME4jmbi8tF5JwcSxEp4xDAb26d/En8L 141/2Io7Ay7PbEWx22F6CQKxNC7LgiPaChsA91NES/mHcT0Sh0f7XaO78pIeYkQOjvV4 kAPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+LdWOs6V7Uzy6Z9b9wmGwQ/MOW781RtAN59OBClMvJM=; b=iO47UKHOqgyNpMInK45RYuSbd19fO1n5AtHWtAUjk8xE0OG22Ymu2haRjBNPXa+PIw I3htIMJhc+ngf0rKedY22sE99PJqJw6gcJDLM88qLPARUWL3SKwYEw308lrQlQU3aSDU GABAn3JFNWcDPjY/zwDf7wwFPQY0qsPpSh3KcSEFkgkSLRXfpWbU41V0PqWQdKTMdPUj djrS9XW3/mJMD784dA5EFmtq8XIBmjx91iVrJD4y5NOiMefuu0Dj5ye8kcUZO7z/8z76 idWnsaWj8LAW0FjO5VulNN4Q7GGozCfidM984VIq5UNIaMQYcypL3dLNyKZHawWwRDMk to9g== X-Gm-Message-State: AOAM5306//gJ/t6eC2mYC2R76/P1ovo/GfU8KwVKqFTDpdLThoRq5csf EPj2sMirYAv2K3Blo+d869NXo01v/qQfq/0Qwggtlp0SV/0= X-Google-Smtp-Source: ABdhPJyyrZvkTdhqat4ghIzx7Ye8ieTjfBiOKqUejkJUJ7mV4EYeoq6gXjEkjWvJ2PCSeuFuPFioACX9VlmeuyFQ3qg= X-Received: by 2002:a17:906:1e0c:b0:6cf:d014:e454 with SMTP id g12-20020a1709061e0c00b006cfd014e454mr7524165ejj.583.1648149460652; Thu, 24 Mar 2022 12:17:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 24 Mar 2022 13:17:29 -0600 Message-ID: To: Rowan Tommins Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="00000000000023978805dafbb399" Subject: Re: [PHP-DEV] Typed constants revisited From: mbniebergall@gmail.com (Mark Niebergall) --00000000000023978805dafbb399 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 24, 2022 at 1:00 PM Rowan Tommins wrote: > On 23/03/2022 18:54, Mark Niebergall wrote: > > The next phase of work with different RFC would take > > this further with const inheritance, where const type must match. > > > I'm not sure it makes much sense to split this into two RFCs, and as far > as I can see, the previous RFC included both features: > > > Class constants are covariant. This means that the type of a class > constant is not allowed to be widen during inheritance. > > > Or is there something more you mean by "const inheritance", which isn't > covered by the RFC's examples? > Agreed, the more discussion that is going on, the more I'm leaning towards to see this implemented in a single RFC. The true value comes with the full feature set. Correct the original RFC discusses some inheritance, but didn't expand it out the way I'm thinking. It only details ensuring the concrete class has a matching type. I'm proposing additionally allowing blank values to be set by the concrete class. Existing draft RFC (https://wiki.php.net/rfc/typed_class_constants): ``` class Test { private const int A = 1; public const mixed B = 1; public const int C = 1; } class Test2 extends Test { // this is legal (because Test::A is private) public const string A = 'a'; // this is legal public const int B = 0; // this is illegal public const mixed C = 0; } ``` What I'm proposing would further allow const without values in abstracts and interfaces, which require concrete classes to have a value: ``` abstract class Test { private const int A = 1; public const mixed B = 1; public const int C = 1; // no value set, this is legal, concrete classes must set value public const int D; } interface TestInterface { // no value set, this is legal public const string NAME; } class Test2 extends Test implements TestInterface { // this is legal (because Test::A is private) public const string A = 'a'; // this is legal public const int B = 0; // these are required due to inheritance public const int D = 5; public const string NAME = 'EmperorPenguin'; // this is illegal public const mixed C = 0; } ``` > > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > --00000000000023978805dafbb399--