Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112471 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 18198 invoked from network); 8 Dec 2020 20:31:07 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 8 Dec 2020 20:31:07 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2045618050A for ; Tue, 8 Dec 2020 12:00:23 -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.5 required=5.0 tests=BAYES_00,KHOP_HELO_FCRDNS, SPF_HELO_NONE,SPF_NONE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from processus.org (ns366368.ip-94-23-14.eu [94.23.14.201]) (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 ; Tue, 8 Dec 2020 12:00:22 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by processus.org (Postfix) with ESMTPA id 175305101324 for ; Tue, 8 Dec 2020 20:00:19 +0000 (UTC) To: internals@lists.php.net References: <79044037-4cd4-4065-a3c1-39a4deea3e09@www.fastmail.com> <763bd813-88f4-4981-820d-a1e50e4c2e1e@www.fastmail.com> Message-ID: <67459aea-24e0-84c9-03a5-390c1a4c7551@processus.org> Date: Tue, 8 Dec 2020 21:00:19 +0100 MIME-Version: 1.0 In-Reply-To: <763bd813-88f4-4981-820d-a1e50e4c2e1e@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Authentication-Results: processus.org; auth=pass smtp.auth=pierre-php@processus.org smtp.mailfrom=pierre-php@processus.org X-Spamd-Bar: / Subject: Re: [PHP-DEV] [RFC] Enumerations From: pierre-php@processus.org ("Pierre R.") Le 08/12/2020 à 18:40, Larry Garfield a écrit : > 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 Hello, I'm really glad to see all of you working hard on this, I have nothing more interesting to say than "Thank you", all of you, very much. And for the record I didn't say so because I didn't want to raise any flame or troll, but now that Nikita put it on the carpet, I'm free to say that implementation choices did make me fear for performances, but they are implementation details, and future can always improve it. Now I don't fear anymore, thanks ! Have a good confined holidays all ! Regards, Pierre