Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112475 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 39448 invoked from network); 9 Dec 2020 19:18:28 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 9 Dec 2020 19:18:28 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 25D551804DD for ; Wed, 9 Dec 2020 10:47:58 -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=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) (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, 9 Dec 2020 10:47:57 -0800 (PST) Received: by mail-qt1-f176.google.com with SMTP id 7so1721186qtp.1 for ; Wed, 09 Dec 2020 10:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SYCvygdm19DZoLdPEfs+YCUo1YABoLTZZYP+PTbR+rU=; b=1d7cO0VoZHNSCSt8GUjEBn+3qjPkY0oNnybA9JCcu9mdyKsiuIsjfINajWIbvBxgln +/kKu3kx9jO7gb6l5A+Dfm/o1xaIr9oekNx0oPkMP4inYxSL/xgH2wFgjCtk7NwoEBN2 GtHuqIibs+Mqq6v5ds7R+Euh3WvdRtFtLfv37sX0Y8eSLunDM70ub+15PdFAI1iJxnCo ebP7oT+pxpasOpABTck4AVQM1hwc+ETOJfIT9fGB86Ozo5u1vQutRzoylZqPeY0krZwY +hNXn5R03KuZQTVQLvvQdWut9a3AKZ7CkEqySrjVTlDmtybK5DCWN9EC77sb0OJIm1r5 Eckw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SYCvygdm19DZoLdPEfs+YCUo1YABoLTZZYP+PTbR+rU=; b=nIYeRcXih920/MqPFL6YiMk6RGpWIlV7kld3M+KXGyqY8ZnxZ903eT3oZXKhTMTfsB b2+K8olSSxZhg/rg/AgDFh1DP0fvIxmpRYBcvRcVJRPliWN2me05T9AuqHr5YicjMc9p uV+ZkPexGSkY1CaUHiVafD/rU6/ZYOUf27BaGeBc90g8Bxly3g9j50JUGjKY4LFL3o1P i253+BnDiYQ608VRRwfnVvZxoTrJxrUO57pWDghlH4O9UHpl32bIrRKAoPLATMeVYsh8 D4IBYXh20oRYQ70ru1sa6vz96xIODCbXjFmWXbuSulAFcKmRoqI/DrySYRo33Li2Z7d2 jMEA== X-Gm-Message-State: AOAM530Vv/6L1pzAPMsiIWKTpyfJO7l8yqe0W9pC1R6Ci/ZCYjDUGk60 lwDOSqUc+TFK1tiElvbA3qM5gCAtwCASm+tj X-Google-Smtp-Source: ABdhPJw4LRgbJ29QDhM7Oi2WQjGLwzrFCABAdZxhNT/45WOb7FvdW+l63q8XR6D8KgSbbhexKNAxfA== X-Received: by 2002:ac8:58d1:: with SMTP id u17mr4681497qta.158.1607539672954; Wed, 09 Dec 2020 10:47:52 -0800 (PST) Received: from [192.168.1.226] (c-24-98-254-8.hsd1.ga.comcast.net. [24.98.254.8]) by smtp.gmail.com with ESMTPSA id 72sm1712200qkn.44.2020.12.09.10.47.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Dec 2020 10:47:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) In-Reply-To: Date: Wed, 9 Dec 2020 13:47:50 -0500 Cc: php internals Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Larry Garfield X-Mailer: Apple Mail (2.3608.120.23.2.4) Subject: Re: [PHP-DEV] [RFC] Enumerations From: mike@newclarity.net (Mike Schinkel) > On Dec 4, 2020, at 6:24 PM, Larry Garfield = wrote: >=20 > Greetings, denizens of Internals! >=20 > Ilija Tovilo and I have been working for the last few months on adding = support for enumerations and algebraic data types to PHP. This is a = not-small task, so we've broken it up into several stages. The first = stage, unit enumerations, are just about ready for public review and = discussion. >=20 > The overarching plan (for context, NOT the thing to comment on right = now) is here: https://wiki.php.net/rfc/adts >=20 > The first step, for unit enumerations, is here: >=20 > https://wiki.php.net/rfc/enumerations Great work. >=20 > There's still a few bits we're sorting out and the implementation is = mostly done, but not 100% complete. Still, it's far enough along to = start a discussion on and get broader feedback on the outstanding nits. 1. Will enum methods be idempotent? =20 If not, shouldn't they be? --------- 2. Will enum cases be able to have attributes applied given the change = in implementation? --------- 3. "Cases are not intrinsically backed by a scalar value." Completely agree with not using an ordinal value. It is too easy to = change an ordinal value and break some hidden dependency. However, I would ask we consider a default string value, i.e. that this: enum Size { case Small; case Medium; case Large; }=20 Would be equivalent to: enum Size { case Small =3D 'Small'; case Medium =3D 'Medium'; case Large =3D 'Large'; }=20 The justification is for use-cases with a large number of cases it would = be too easy to have typos and/or copy-paste errors if the developer has = to explicitly specify the value. Also, the following would leave the values of Medium and Large undefined = given that enumerations supports only a single type at a time: enum Size { case Small =3D 1; case Medium; case Large; }=20 So, can enums get a default value of their name as a string when zero = values are provided? --------- 4. "Class/Enum inheritance. - Enums are by design a closed list" I would ask if this is really necessary to disable inheritance?=20 Consider the following as a example where I use a known list for clarity = but where I am really more interested is lists a developer maintains, = i.e. their own apps list of errors: enum OsErrors { case EPERM =3D 1; case EINTR =3D 4; case EIO =3D 5; case ENXIO =3D 6; case E2BIG =3D 7; .... }=20 enum FileErrors extends OsErrors { case ENOENT =3D 2; case ENOEXEC =3D 8; case EBADF =3D 9; .... }=20 enum ProcessErrors extends OsErrors { case ESRCH =3D 3; case ECHILD =3D 10; .... }=20 Without inheritance a developer could not create a new error enum, such = as SpeachRecognitionErrors and be able to include the base errors = without having to duplicate them. Now it is very possible that someone can focus on my example and explain = why enums are not the right solution here, but please do not to that. =20= Instead please consider without inheritance nobody would be able to = reuse a base set of enums w/o duplication of names and/or values.=20 So can we revisit the idea of disallowing inheritance? --------- 5. Someone else mentioned shortcut syntax, which I would like to mention = again, although I realize implement details might make this a = non-starter. =20 So if I have a function that accepts a Size from above, e.g.: function show(Size $size) {} Then it would be great if we could call the function like this since its = parameter was type-hinted: show(::Medium)=20 Rather than always having to write: show(Size::Medium)=20 So can we consider a shortcut syntax? --------- > I should note that while the design has been collaborative, credit for = the implementation goes entirely to Ilija. Blame for any typos in the = RFC itself go entirely to me. >=20 > *dons flame-retardant suit* >=20 > --=20 > Larry Garfield > larry@garfieldtech.com >=20 > --=20 > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >=20 Again, great work! -Mike=