Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88340
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CAFMT4NqssqRWMA+OQz4nXWOzttf47Q9Lu4ybHpWSNOitHY-MFw@mail.gmail.com>
References: <55FB4791.4040807@gmail.com>
	<CAB6YZuzwhSYC9fQCa1w=aiHWTvTAFyrhC4BdBo0w8n6i=M3f7g@mail.gmail.com>
	<CAFMT4Nr1sP=Rst-kuUEKNoG8NL7j75dc3Gi8ti5RcEO4Am4yTg@mail.gmail.com>
	<55FC34E6.8020009@gmail.com>
	<CAFMT4NqssqRWMA+OQz4nXWOzttf47Q9Lu4ybHpWSNOitHY-MFw@mail.gmail.com>
Date: Fri, 18 Sep 2015 11:04:44 -0600
Message-ID: <CAFMT4NqxsSLrYHhZ+7f9nQY_-kjDr86YoHc5PLmAhYc=LQ3itQ@mail.gmail.com>
To: Jefferson Gonzalez <jgmdev@gmail.com>
Cc: =?UTF-8?Q?Pavel_Kou=C5=99il?= <pajousek@gmail.com>, 
	Rowan Collins <rowan.collins@gmail.com>, internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Let's discuss enums!
From: levim@php.net (Levi Morrison)

(CC'ing internals as it was apparently dropped by Jeff)

On Fri, Sep 18, 2015 at 11:03 AM, Levi Morrison <levim@php.net> wrote:
> On Fri, Sep 18, 2015 at 9:59 AM, Jefferson Gonzalez <jgmdev@gmail.com> wr=
ote:
>> On 09/18/2015 10:21 AM, Levi Morrison wrote:
>>>
>>> On Fri, Sep 18, 2015 at 1:05 AM, Pavel Kou=C5=99il <pajousek@gmail.com>=
 wrote:
>>>>
>>>> On Fri, Sep 18, 2015 at 1:06 AM, Rowan Collins <rowan.collins@gmail.co=
m>
>>>> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> This has come up in passing a few times recently, but I'm not sure
>>>>> there's
>>>>> ever been a dedicated discussion of it: would it be useful for PHP to
>>>>> have a
>>>>> built-in Enumeration type, and if so, how should it look?
>>>>>
>>>>> Many other languages have enum types, with varying functionality. The
>>>>> central concept is always that there's some declared type with a bunc=
h
>>>>> of
>>>>> named constants, but beyond that there's a lot of variability: for
>>>>> starters,
>>>>> is it a type of object, a special way of naming integers, or an
>>>>> uncomparable
>>>>> type more like booleans and nulls?
>>>>>
>>>>>
>>>>> So, what are anyone's thoughts? Am I rambling on too much as usual? ;=
)
>>>>>
>>>>> Regards,
>>>>>
>>>>> --
>>>>> Rowan Collins
>>>>> [IMSoP]
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> personally, I feel that you should be able to assign numeric value to
>>>> each element (and have them implicit if not specified).
>>>>
>>>> This is imho better for serialization (but it can be done with names
>>>> as well, yeah) - but more importantly, it also allows usage with
>>>> bitwise operators, so you could use them as a "flags" (ie. $weekend =
=3D
>>>> Days::SATURDAY | Days::SUNDAY).
>>>
>>>
>>> In my opinion this is the least valuable form of enums that exists in
>>> any language I am aware of. However I was careful in the RFC to not
>>> prevent this from being a possibility. I would much, much prefer enums
>>> that are more like Rust's, Haskell's or Swift's. It's worth noting
>>> Swift has at least three different kinds of enums, one of which would
>>> allow the kind of behavior you are wanting.
>>>
>>
>> It may not be valuable in your opinion, but I have seen this kind of enu=
m
>> usage on a lot of open source projects which is really useful to represe=
nt
>> more than 1 value in a single variable, which would be more efficient an=
d
>> less memory consuming than doing something like:
>>
>> $weekend =3D array(
>>     Days::SATURDAY;
>>     Days::SUNDAY;
>> )
>>
>> And anyway, most new languages have over engineered the purpose of enums=
.
>> Enums should just be a nice way of grouping constant values with a human
>> readable name where the ordinal value should be optionally set for
>> consistency in case that storing it is required.
>
> According to type theory the enumerated type is just a special case of
> the union type where each type constructor in the union takes exactly
> zero parameters (meaning they are all singletons). So=E2=80=A6 what is th=
e
> purpose of an enumerated type? To create a finite set of values that
> are all unique. That's it =E2=80=93 that's the whole purpose.
>
> Anything else is trying to add value in some way =E2=80=93 in your case y=
ou
> are adding a primitive value that the language will automatically map
> for you. I'm not saying that is a bad thing but I hope you can at
> least recognize that it is an addition and not the bare minimum. The
> RFC I am planning on proposing will have only the bare minimum because
> it's the least controversial part and is the most useful. The other
> stuff we can debate about later.