Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88295
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.105 as permitted sender)
Message-ID: <BLU436-SMTP2172CD0AD39FA39E66612EE25A0@phx.gbl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F1214073-3E51-4E8C-9579-A91EE50F102D"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
In-Reply-To: <55FB4791.4040807@gmail.com>
Date: Fri, 18 Sep 2015 01:16:23 +0200
CC: internals@lists.php.net
References: <55FB4791.4040807@gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] Let's discuss enums!
From: bobwei9@hotmail.com (Bob Weinand)

--Apple-Mail=_F1214073-3E51-4E8C-9579-A91EE50F102D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

> Am 18.09.2015 um 01:06 schrieb Rowan Collins =
<rowan.collins@gmail.com>:
>=20
> Hi All,
>=20
> 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?
>=20
> Many other languages have enum types, with varying functionality. The =
central concept is always that there's some declared type with a bunch =
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?
>=20
>=20
> Here are my thoughts on what I'd like from a PHP enum - I'm not using =
"should" in a particularly strong sense, it's just a way of framing the =
points of discussion:
>=20
> 1) enums should act like values, not mutable objects; an array-style =
copy-on-write behaviour would be possible, but it feels wrong to me to =
store any state in an enum variable, so just plain immutable would be my =
preference
>=20
> 2) the members of an enum should have a name which is accesible as a =
string, e.g. Weekdays::SUNDAY->getName() =3D=3D 'SUNDAY'
>=20
> 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)
>=20
> 4) each enum member should be considered a singleton, in the sense =
that you can't construct or destroy one, only reference them; all =
possible instances would be created as soon as the enum was defined
>=20
> 5) following from (3) and (4), an enum value should compare equal only =
to itself, unlike in C# for instance, where it would be comparable to an =
integer based on its numeric value; similarly it shouldn't be possible =
to cast to or from an enum
>=20
> 6) an enum should be able to have additional fields; these would be =
initialised in the enum's definition; this is inspired by Java and =
Python's ability to pass parameters to the "constructor" of the enum, =
but it feels weird to me for any logic to happen in that constructor =
other than simple assignments, so I'm thinking of a simpler syntax and =
implementation. It also simplifies immutability if no userland code ever =
writes to the properties. There may be an important use case for =
constructor logic I'm missing though?
>=20
> 7) an enum should have default static methods for accessing all the =
members of the enum as an associative array
>=20
> 8) enums should be a first-class type, is_object(Weekdays::SUNDAY) =
should return false, for instance; maybe Weekdays::SUNDAY instanceof =
Weekdays should return true though
>=20
> 9) additional static and instance methods should be definable, bearing =
in mind the immutability constraints already discussed
>=20
>=20
> Given the above, I think we might end up with something like this:
>=20
> enum Weekdays {
>    member MONDAY; // if there are no fields to initalise, the member =
just needs its name declaring
>    member TUESDAY ( 2, 'Chewsdae' ); // positional arguments for =
populating fields in the order they are defined; a bit like Java, but =
without the constructor
>    member WEDNESDAY { $dayNumber =3D 3, $sillyName =3D 'Wed Nose Day' =
}; // or maybe a named-parameter syntax to make things clearer
>    member THURSDAY, FRIDAY, SATURDAY, SUNDAY; // don't force people to =
write each entry on its own line; maybe even the "member" keyword is too =
much?
>=20
>    public $dayNumber, $sillyName; // fields initialised for each =
member
>=20
>    public static function getWeekend() {
>         return [ self::SATURDAY, self::SUNDAY ];
>    }
>=20
>    public function getZeroIndexedDayNumber() {
>         return $this->dayNumber - 1;
>    }
> }
>=20
> $today =3D Weekdays::THURSDAY;
> foreach ( Weekdays::getMembers() as $day_name =3D> $day ) {
>    echo $day->dayNumber;
>    if ( $day =3D=3D $today ) {
>       echo "Today!";
>    } else {
>       echo $day_name; // equivalently: echo $day->getName();
>    }
> }
>=20
> // Do we need a static method to access a member by name, or is this =
good enough?
> $favourite_day =3D Weekdays::getMembers()[ $_GET['fav_day'] ];
>=20
> So, what are anyone's thoughts? Am I rambling on too much as usual? ;)
>=20
> Regards,
>=20
> --=20
> Rowan Collins
> [IMSoP]

I like enums in general, but I'd like to note that there's already a RFC =
in draft by Levi:

https://wiki.php.net/rfc/enum <https://wiki.php.net/rfc/enum>

As far as I know, the RFC is already fairly final and just lacks an =
implementation.

So, I'd consider bikeshedding an actual RFC first.

Bob=

--Apple-Mail=_F1214073-3E51-4E8C-9579-A91EE50F102D--