Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112469 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 3716 invoked from network); 8 Dec 2020 18:11:59 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 8 Dec 2020 18:11:59 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CB32C18050A for ; Tue, 8 Dec 2020 09:41:12 -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,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 8 Dec 2020 09:41:12 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id EA7444B6 for ; Tue, 8 Dec 2020 12:41:09 -0500 (EST) Received: from imap26 ([10.202.2.76]) by compute4.internal (MEProxy); Tue, 08 Dec 2020 12:41:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=JlbhWj OwbjhO5Nfy8fwe8eoT4G7UsLmiycX034b6dr0=; b=IRHNYSwWAIUQwsKXChuBbq iZkFGc1oUHPTbejlqVuzQS93pDmVwSDxKSMidd4H4AtNhS+ECQdBvdsP3MDh/AfF uHuRYqHXfse8VbgEEH88/4d2pihv14MoIvdwRLCYvGnGUWAUglvpZti9/8iyFk/y FwUiMOGh9EnLg5ipTASy9NViujaG6IJ/QbkaG/fVqCXaA1uWM0+e5Zve9rsIxuNB QYI0YtS0xOjw9L24ztftj7MglupU6LxkLEhHrzXPd6B8CXCQTnLdHEVsSkDvvPOC dkxKuzmjYlwwLRRjf/+ftSbXlP6FNGS20IO9qqIpZSOmX/Ij4hmg/pdjJF3GPYMg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejiedguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgr rhhrhicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtg homheqnecuggftrfgrthhtvghrnhepveehhedvveejledvvefgleevffdtjeekledvkeeg heffgfeivdejhffhledtudetnecuffhomhgrihhnpehphhhprdhnvghtnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheplhgrrhhrhiesghgrrhhf ihgvlhguthgvtghhrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 05C0D14200A2; Tue, 8 Dec 2020 12:41:09 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-ID: <763bd813-88f4-4981-820d-a1e50e4c2e1e@www.fastmail.com> In-Reply-To: <79044037-4cd4-4065-a3c1-39a4deea3e09@www.fastmail.com> References: <79044037-4cd4-4065-a3c1-39a4deea3e09@www.fastmail.com> Date: Tue, 08 Dec 2020 11:40:48 -0600 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] [RFC] Enumerations From: larry@garfieldtech.com ("Larry Garfield") On Sat, Dec 5, 2020, at 2:26 PM, Larry Garfield wrote: > On Fri, Dec 4, 2020, at 5:24 PM, Larry Garfield wrote: > > Greetings, denizens of Internals! > > > > 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. > > > > The overarching plan (for context, NOT the thing to comment on right > > now) is here: https://wiki.php.net/rfc/adts > > > > The first step, for unit enumerations, is here: > > > > https://wiki.php.net/rfc/enumerations > > > > 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. > > > > 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. > > > > *dons flame-retardant suit* > > > > -- > > Larry Garfield > > larry@garfieldtech.com > > Thank you everyone for the feedback so far! I've updated the RFC with > a few changes, based on discussion here and elsewhere: > > * Clarified that "enums behave like objects unless otherwise > specified." That should clarify a lot of edge case questions. (Which > is specifically one of the reasons to build off of objects. We can > inherit answers to most edge cases.) > * Primitive-backed Cases have been renamed to Scalar Enums, because > "Primitive-backed" is just too clumsy to say or write all the time. > * There's now formal internal interfaces defined for Enum, UnitEnum, > and ScalarEnum to define the methods mentioned. These serve as both > documentation and to allow user-space code to tell when a value it's > dealing with is an enum, and a particular type of enum. (And therefore > what enum methods are available.) > * Added a value() method to ScalarEnum, to make it easier to get at the > scalar equivalent arbitrarily. > * Fixed a bunch of typos. > * Updated the reflection section to have getType() return a > ReflectionType rather than a bare string. > > (The patch will be updated for the above shortly as Ilija's time allows.) Another update: Based on feedback here, and after further discussion with Ilija and NIkita, we're going to try a different tack on some implementation details. Specifically: * We're going to shift Enums to be a single class with a bunch of secret properties inside to hold the different case object instances, rather than a class per case. That should make the overall memory usage lower, especially for enums with a large number of cases. As an unfortunate side effect, this will preclude per-case methods, at least for now. :-( * The ReflectionCase class will naturally go away at that point. * For serialization, we'll introduce a new serialization marker, enum, which will make it feasible too round-trip an enum while maintaining singleton-ness. More specifically, the deserialize routine would essentially become $type::from($value), where $type and $value are pulled from the serialized version. I was also wrong in one of my earlier statements; as currently implemented, enum cases are implemented as class constants that reference an object. (Something the engine is allowed to do even if user code cannot.) That means they *do* work as parameter defaults and can be assigned as a default value of an object property or constant. Huzzah! Because it's the holidays these changes won't be immediate, but expect us to come back in a few weeks with the next draft. Thank you everyone for your interest! --Larry Garfield