Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117460 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 65608 invoked from network); 30 Mar 2022 13:07:10 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 Mar 2022 13:07:10 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2302C1804F5 for ; Wed, 30 Mar 2022 07:35:40 -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-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) (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 ; Wed, 30 Mar 2022 07:35:39 -0700 (PDT) Received: by mail-ej1-f45.google.com with SMTP id bi12so42019248ejb.3 for ; Wed, 30 Mar 2022 07:35:39 -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=rHSYOI5UrDfR3qz1UY1QNb10SnGDJCaAHCo4wi1R9Ms=; b=Chmx/w0AZvkKdowgVDi2zTnKNvrOOfg2ECjIj+XHXq1vrjaD8MJj8V02D4PGpGRPXW ONHlsRwOWaJzjqAnyRlf48byA4RHN74GC1Ey5RqMYwL2I6yH0k+HeEc4dPUrMxOc8879 Vv+fyJYdB2hA+7ki0XWlz/7EktYstKZL2RPfoaFPE2/YBIZW4F1sCyN5yq/jIOrhDFXU UYtAzbDsqUioTg3jdLPhazGKR2jNRjdtedWn6pYf0/feSJsY8q1JMoyNf83e3hMrSyAP PA0GYznoj6UU6T7OVDwQTpAHzYW6UuXSXXWNdo0tKvhKNpbuc8150mToDL+aqA0h9QRB fkJw== 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=rHSYOI5UrDfR3qz1UY1QNb10SnGDJCaAHCo4wi1R9Ms=; b=RFeki3KjMSx/ZPH0uq8GghjgP6oxExnuZFqoTpTWcE6/u/Visydw0MriD2wJ25/Pxo KlnEZVXxDh2X8RxbhExNoyYOIgxBJfVcd1PO9qWyH3+swrHEL+ew24+Xd3yI9+at0SeP 3wvPOpgOSfRou7sQyxj1OmUPQTjO3cRk0D8jXK9anTdzp9EV5984JC3tAZDbUFkjD0Rn ob98NevrGT14ytsHltbLBcQi8ENaU5yCyABZKVGyHioAI0C4DxAkmfCBwM9Ozp7B0o8+ yPciliXvZOcO910B1IBw9b6VOn1gFHq4JAKYCpk+bV4MycYlEV/hdDJnMfjSBz82M9B0 YQRA== X-Gm-Message-State: AOAM531AbD913MEbu0HXBnUjO/3YzCMLL1DUhIhEALZDpplvqZOvdgVt t+UDPru6gTj+84i+T+ekzHwSlMLN/srPcMyedbZQ7VjwBHY= X-Google-Smtp-Source: ABdhPJxewQ5HcwfRxmPwhEy4w9uW0jcThWTAGqNw8PWjidXpx95qVIDLYm0tgyuZW76JVwspYYfSZ6LTIMJ02ZWS7Xk= X-Received: by 2002:a17:907:7ea7:b0:6df:fb36:e8af with SMTP id qb39-20020a1709077ea700b006dffb36e8afmr40598071ejc.356.1648650938056; Wed, 30 Mar 2022 07:35:38 -0700 (PDT) MIME-Version: 1.0 References: <76c399cb-fb29-4583-a212-8eb69740c96b@www.fastmail.com> In-Reply-To: Date: Wed, 30 Mar 2022 08:35:26 -0600 Message-ID: To: Guilliam Xavier Cc: php internals Content-Type: multipart/alternative; boundary="000000000000859cfe05db70754c" Subject: Re: [PHP-DEV] Typed constants revisited From: mbniebergall@gmail.com (Mark Niebergall) --000000000000859cfe05db70754c Content-Type: text/plain; charset="UTF-8" Guilliam, On Wed, Mar 30, 2022 at 7:50 AM Guilliam Xavier wrote: > Hi Mark, > > I have updated the RFC https://wiki.php.net/rfc/typed_class_constants with >>>> more details and examples from this thread, and updated the RFC status >>>> to >>>> Under Discussion. Hopefully the updated RFC helps answer questions and >>>> clarifies what the proposal includes. >>>> >>> > Thanks (I assume that you talked with the original author) -- not sure if > you should have started a new thread with the "[RFC]" tag in the subject? > I will address the issues from you and Alex in the RFC page, then start a new thread with "[RFC]" since you are correct this has moved past initial testing-the-waters and is now into the discussion phase about the RFC. I reached out multiple times to the original author but have not received a response. I did leave Benas as an author to give him credit for the work he did. > > >> I think you should also update the "Supported types" section. >>> Starting with enums, constants can also be objects. Once a good >>> technical solution is found, any object would be supported probably >>> https://wiki.php.net/rfc/new_in_initializers#future_scope >>> I think that only void, never and callable types should not be >>> supported, just like on properties. >>> >> >> I have updated the "Supported types" to list out all types that are >> supported and which types are not supported. >> > > A few comments, by subsection: > > - **Supported types**: This corresponds to the types currently allowed > for const values (as well as unions thereof) except it [still] doesn't > mention enums (which internally are classes implementing the `UnitEnum` > interface, and whose values are ultimately of `object` type) although > currently allowed. It also doesn't mention `mixed` (used later in examples). > - **Strict and coercive typing modes**: I didn't understand it on first > read; I had to read the later "Constant values" section and compare both > with > https://wiki.php.net/rfc/typed_properties_v2#strict_and_coercive_typing_modes > and https://wiki.php.net/rfc/typed_properties_v2#default_values > - **Inheritance and variance**: Several occurrences of "Class constants" > should probably be "*Typed* class constants". Also, I still think that > `protected bool $isExtinct` is *not* a good parallel to `public const bool > CAN_FLY` (see my previous message). > - **Constant values**: You should probably remove the `iterable` example > now [and maybe add an `enum` one]. > Thanks for the input, I'll work on addressing those. > > >> Constants cannot be objects since objects are mutable, so typed constants >> will not be allowed to be an enum (which is technically an object). A typed >> constant _may_ be an enum value though, so the following example will be >> valid: >> >> ``` >> enum Fruit >> { >> case Apple; >> case Banana; >> } >> >> class Colors >> { >> protected const string RED = Fruit::Apple; >> protected const string YELLOW = Fruit::Banana; >> } >> ``` >> > > This is incorrect, `Fruit::Apple` is of type `Fruit` (ultimately > `object`), not `string`. But it is *not* mutable, and *is* allowed as a > const value currently. > Yes, Alex also identified this issue in my examples, I will correct that and include enum examples in an updated RFC. I will do that before starting an "[RFC]" thread. > > Besides, I realized that the RFC is [only] for *class* constants; what > about *namespaced (and global)* constants? > Ah yes, I hadn't considered expanding this RFC to namespaced and global constants. Let me mull over implementation syntax for those and include them in the RFC. My initial reaction is to not include those in this RFC, keeping the scope to just class constants. If there is value in typing namespaced and global constants, then another RFC could add those. Once I have all these new issues figured out and the RFC updated, I'll start that new thread. > > Regards, > > -- > Guilliam Xavier > --000000000000859cfe05db70754c--