Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:88297 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78938 invoked from network); 17 Sep 2015 23:34:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Sep 2015 23:34:29 -0000 X-Host-Fingerprint: 24.41.170.168 unknown Received: from [24.41.170.168] ([24.41.170.168:9045] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DA/81-05737-40E4BF55 for ; Thu, 17 Sep 2015 19:34:28 -0400 To: internals@lists.php.net,Rowan Collins , internals@lists.php.net References: <55FB4791.4040807@gmail.com> Message-ID: <55FB4DFC.2060204@domain.invalid> Date: Thu, 17 Sep 2015 19:34:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55FB4791.4040807@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 24.41.170.168 Subject: Re: Let's discuss enums! From: user@domain.invalid On 09/17/2015 07:06 PM, Rowan Collins wrote: > 3) there should be no accessible "value" for a member; the value of > Weekdays::SUNDAY is simply Weekdays::SUNDAY, not 0 or 7 or 'SUNDAY' (I'm > thinking that internally, each member would be represented as an object > pointer, so there's no real benefit to forcing people to number > everything like some languages do) Well, how are you supposed to serialize an enum value without some sort of numerical representation or value? Maybe you could serialize it by converting the enum to a string representation of its name but that wouldn't be efficient and also if a developer refactored its code base and renamed an enum, when unserializing the data it wouldn't be properly assigned. Also other languages don't force you to assign value for an enum constants, if I recall correctly languages like C/C++ automatically assing an interger value to enumerations in they order they were typed so: enum BadDays {MONDAY, SUNDAY, THURSDAY=5, SATURDAY} would be MONDAY = 0, SUNDAY = 1, THURSDAY=5, SATURDAY=6 So assigning a value is optional. I see the enum's rfc mentions boxing primitive types but that seems to not solve what I'm saying here at all. Enums should be a nice way of grouping constant values without hitting on the performance (for everything else use a class). The rfc is proposing a nice syntax but it doesn't fully covers serialization/unserialization of enumerations.