Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88296
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55FB4791.4040807@gmail.com>
References: <55FB4791.4040807@gmail.com>
Date: Thu, 17 Sep 2015 20:16:21 -0300
Message-ID: <CAOsHV+tE_JCd05K8iTgRoEi40n_ryOJ0E0fqCESae9Vep9F=vw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP 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: marcio.web2@gmail.com (Marcio Almada)

Hi,

2015-09-17 20:06 GMT-03:00 Rowan Collins <rowan.collins@gmail.com>:
> 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 hav=
e 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 bunch of
> named constants, but beyond that there's a lot of variability: for starte=
rs,
> is it a type of object, a special way of naming integers, or an uncompara=
ble
> type more like booleans and nulls?
>
>
> 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:
>
> 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 st=
ore
> any state in an enum variable, so just plain immutable would be my
> preference
>
> 2) the members of an enum should have a name which is accesible as a stri=
ng,
> e.g. Weekdays::SUNDAY->getName() =3D=3D 'SUNDAY'
>
> 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 everythin=
g
> like some languages do)
>
> 4) each enum member should be considered a singleton, in the sense that y=
ou
> can't construct or destroy one, only reference them; all possible instanc=
es
> would be created as soon as the enum was defined
>
> 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
>
> 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 a=
lso
> simplifies immutability if no userland code ever writes to the properties=
.
> There may be an important use case for constructor logic I'm missing thou=
gh?
>
> 7) an enum should have default static methods for accessing all the membe=
rs
> of the enum as an associative array
>
> 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
>
> 9) additional static and instance methods should be definable, bearing in
> mind the immutability constraints already discussed
>
>
> Given the above, I think we might end up with something like this:
>
> enum Weekdays {
>     member MONDAY; // if there are no fields to initalise, the member jus=
t
> needs its name declaring
>     member TUESDAY ( 2, 'Chewsdae' ); // positional arguments for populat=
ing
> 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?
>
>     public $dayNumber, $sillyName; // fields initialised for each member
>
>     public static function getWeekend() {
>          return [ self::SATURDAY, self::SUNDAY ];
>     }
>
>     public function getZeroIndexedDayNumber() {
>          return $this->dayNumber - 1;
>     }
> }
>
> $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();
>     }
> }
>
> // 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'] ];
>
> So, what are anyone's thoughts? Am I rambling on too much as usual? ;)
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>

A kitten is working on that https://wiki.php.net/rfc/enum. Many points
on the linked RFC are compatible to the points you raised so it might
be worth reading before even starting any new proposal.

Regards,
M=C3=A1rcio