Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113525 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 76904 invoked from network); 14 Mar 2021 22:25:18 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Mar 2021 22:25:18 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1542A1804E3 for ; Sun, 14 Mar 2021 15:18: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, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) (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, 14 Mar 2021 15:18:39 -0700 (PDT) Received: by mail-yb1-f178.google.com with SMTP id f145so14913572ybg.11 for ; Sun, 14 Mar 2021 15:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=PQ75ef37+V7AQ8phaaq3Zf4Xg2U7I87lwEYWPngUJBM=; b=Usxax+GF6Pcs8GJkBxLSp/QE6r+xLgTEk2wXWMhxW0nYa4NCtLWB8d3fFHfqZhrYMJ T/crgFJ2m26RPOLKwphk/7kJppkH7TgoAtojsL40wznmqif/X6CrEA0vr0+XzR/Fy8SV cVQeynqmTw/H2VBEw3j4J/9J+5v7CxQsV5+4TO2i/avIiSTh75VezYZDcCwUBbqr82CK BTCdABx15f3XVZU4zHTmNISSJWTbZ0qFBsJn18TVfSxk1xU4oFuqgIo2kcohYWGICt5n k39hVgRFGYiI6uz0aVhHfO4JCzXucjRauWgvvbDJgQzzja9vlLg9CAxlUliqSHF5Y2dB yYIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=PQ75ef37+V7AQ8phaaq3Zf4Xg2U7I87lwEYWPngUJBM=; b=QepatsU8aEe3R75diMovuwQKhT5YLNI9Em0AxX0RN8aq0skcxq3QPDaxrcJGh9l1TC Q4gTf6y5V2NcM0xEr4gEHCpkB+H105oui+jvfzcF3VsbDMa2gs+8khA/YHGR017nxdeo shjtIUpFlQqDDTD43XXHWwld4CeIuUVv+FjUCDxr+p7pxRgGilJFLna6sPbmi1ui2+G2 PiN+g1af4dArIu4dnzhSGkooW1yAIs2MB270ZACso/NlZVj33o3T2L6nXFqu/ldIVyWV P2wo54qHdBFhbhD9sIziL/+Zy/Lw1RHvc03k8OKlko+n2vmCy1DXt4QJYd8l8nhTpxJS FNtw== X-Gm-Message-State: AOAM531AXwDW6oYlycG8+T0rh4bIvBTAnoZxk7GnTlGjpBapeaqGcrnO ct6hNZ6yXoy4QKJCIj1uQ/mOR47Pei5Eajd43y46sXuhhTB3Jg== X-Google-Smtp-Source: ABdhPJxgjwcUzzgg3FPqRIgvVD4HIpPiwVZInxzIPmLV5VMbtiYWB0JsFZZZL4ZMCcZotLOAc3+cJcmrdfYHQIOEWmA= X-Received: by 2002:a25:f805:: with SMTP id u5mr32124235ybd.2.1615760316287; Sun, 14 Mar 2021 15:18:36 -0700 (PDT) MIME-Version: 1.0 References: <2ff5377c-3718-feb1-ba20-96df47357414@mabe.berlin> In-Reply-To: <2ff5377c-3718-feb1-ba20-96df47357414@mabe.berlin> Date: Sun, 14 Mar 2021 23:18:25 +0100 Message-ID: To: PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] Inconsistency in enumerations RFC From: tovilo.ilija@gmail.com (Ilija Tovilo) Hi Marc Thanks for testing the enum feature. > Hi I'm trying out the new enumeration support for PHP 8.1 using > https://github.com/php/php-src/pull/6489 thought to implement a polyfill > based on class constants and reflection. Doing so I come across the > newly defined interfaces: > ``` interface UnitEnum{ > public string$name; > public staticfunction cases(): array ; > } > > interface BackedEnumextends UnitEnum{ > public string$value; > public staticfunction from(int|string$scalar): static; > public staticfunction tryFrom(int|string$scalar): ?static; > } > ``` My interest here is on BackedEnum which (currently) supports > int|string. First of all the interface defines a "public string $value" > but in fact the type needs to be "int|string". As properties are not > supported in interfaces this is a pure documentation issue in the RFC > itself. We intentionally put it in the interface for clarity, even though it's not technically possible yet. > Secondly the arguments name $scalar is not really a good name - > now as we have named arguments - $value would be much more meaningful. I think you might be looking at an older implementation. I only fixed the naming recently (~2 weeks ago). The parameter is called $value, as you suggested. > But most interestingly I get the feeling that this should be split into > several typed interfaces because this makes wrong impression especially > that "tryFrom" would except int|string but actually it doesn't. > Additionally, if we want to support other types later on this would blow > up the types even more. Example: ``` enum Test:string { case TEST = '1'; > } Test::tryFrom('unknown'); // NULL Test::tryFrom(1);// TypeError ``` > The TypeError doesn't make sense here as it matches the type and it even > matches the string representation of an existing type. try/tryFrom will coerce the given value under non-strict_types. With strict_types enabled it will type error. I think this behavior is consistent with the rest of PHP. > I think it would > be much clearer if there would be two different interfaces like: > ``` interface IntEnum extends UnitEnum { public int $value; public > static function from(int$value): static; public static function > tryFrom(int$value): ?static; } > interface StringEnum extends UnitEnum { public string $value; public > static function from(string $value): static; public static function > tryFrom(string $value): ?static; } ``` or else the above example should > return a NULL or even case matching the string representation instead of > TypeError as it matches the defined argument types. I guess the interface would be more accurate. I'm not sure if that's a huge win or just unnecessarily bloats the API. I think using BackedEnum as a type hint should be relatively rare in practice. Optimally we could add an associated type or generic type to BackedEnum but that's currently not possible. Ilija