Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112723 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 64578 invoked from network); 3 Jan 2021 11:20:48 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Jan 2021 11:20:48 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 79F3E1804C6 for ; Sun, 3 Jan 2021 02:56:29 -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.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from wp160.webpack.hosteurope.de (wp160.webpack.hosteurope.de [80.237.132.167]) (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, 3 Jan 2021 02:56:29 -0800 (PST) Received: from [2a02:8109:9d40:1d44:40b6:f5d3:c567:d46c] (helo=nas.fritz.box); authenticated by wp160.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1kw13j-0003vM-9M; Sun, 03 Jan 2021 11:56:27 +0100 To: Larry Garfield , php internals References: <67c9d05a-f0a7-fcea-32ea-7a4e409308a1@mabe.berlin> <5120eee2-56c4-4608-9e41-4dd05563fef7@www.fastmail.com> Message-ID: Date: Sun, 3 Jan 2021 11:56:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <5120eee2-56c4-4608-9e41-4dd05563fef7@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-bounce-key: webpack.hosteurope.de;marc@mabe.berlin;1609671389;b99d43c7; X-HE-SMSGID: 1kw13j-0003vM-9M Subject: Re: [PHP-DEV] [RFC] Enumerations, Round 2 From: marc@mabe.berlin (Marc) On 29.12.20 16:42, Larry Garfield wrote: > On Tue, Dec 29, 2020, at 2:48 AM, Marc wrote: >> On 28.12.20 21:21, Larry Garfield wrote: >>> Hello, Internalians! >>> >>> After considerable discussion and effort, Ilija and I are ready to offer you round 2 on enumerations. This is in the spirit of the previous discussion, but based on that discussion a great deal has been reworked. The main change is that Enumeration Cases are now object instances of the Enumeration class rather than their own class. Most of the other changes are knock-on effects of that. >>> >>> Of particular note: >>> >>> * Cases may not have methods or constants on them. They're just dumb values. >>> * Enums themselves may have methods, static methods, or constants. >>> * Traits are supported, as long as they don't have properties. >>> * The value() method on scalar enums is now a property. >>> >>> The full RFC is here, and I recommend reading it again in full given how much was updated. >> I did and the RFC looks really awesome :+1: >> >> I don't have time to test the implementation but I noticed one thing: >> >>> If the enumeration is not a Scalar Enum, the array will be packed >> (indexed sequentially starting from 0). If the enumeration is a Scalar >> Enum, the keys will be the corresponding scalar for each enumeration. >> >> I don't think using the scalar values as keys is a good idea. What >> happens if we want to support scalar float values? (Why are they >> actually not supported in the first place?) > That's why floats are not supported, in fact, because what happens to them when they are made into an array key is non-obvious. (PHP would say to convert to a string, but that's always fussy with possible data loss in some cases, etc.) We decided to just avoid that problem until/unless someone found a good use case for float enums. No all languages support them as is, so there is precedent. > >> Also I think it's more natural if both enum types return a >> zero-indexed-array of cases. > The goal is to make it easy to work with them, and having a clean lookup map readily available is very convenient. If you don't care about the scalar equivalent then you can safely ignore them. If you do want them, then you have a lookup table ready-made for you. That's the logic we were working from. I don't have a really good use-case for float values. It just seems weird to me that a ScalarEnum doesn't support all scalars. Using the enum value as array key for `cases()` works with your current proposal but if we later want to allow floats, bool whatever then we got a food gun. You already provide a lookup mechanism with `MyEnum::from()` - I don't see a real use-case for proving a pre build map. The main use case I see is to list all possible enum values but this doesn't require a map and a zero-indexed-array would also be more performant with packed arrays (correct me if I'm wrong). > > --Larry Garfield >