Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112701
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-ID: <b24a66e7-30b8-468d-8a36-99aa493834c5@www.fastmail.com>
In-Reply-To: 
 <CABdc3WpWpZCSeMv+mm-4Xp8C8qG4ek5o_-Ln0+RV50OVUEOJ2A@mail.gmail.com>
References: <eadd4a32-a05b-463b-a91f-a5d353c577b2@www.fastmail.com>
 <CABdc3WpWpZCSeMv+mm-4Xp8C8qG4ek5o_-Ln0+RV50OVUEOJ2A@mail.gmail.com>
Date: Thu, 31 Dec 2020 12:13:57 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Enumerations, Round 2
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Dec 31, 2020, at 4:02 AM, Micha=C5=82 Marcin Brzuchalski wrote:
> Hi Larry,

> I really like the shape of the current RFC.
>=20
> I'd like to ask a few things:
>=20
> 1. Regarding the Scalar Enums since scalar values need to be literal a=
nd
> by design they're read only why they use a spear "->value" on enumerat=
ion?
> A spear "->" in objects is dedicated to class properties and by defaul=
t
> they make thinking of property which
> in most cases is read-write visible.
>=20
> An example using Suit enumeration from RFC:
> // when I assign an enumeration to variable
> $var =3D Suit::Spades;
> // then reaching it's value using "->value"
> echo $var->value; // 'C'
> // Looks just like an object property fetch
>=20
> By default if a property is visible it is write accessible as well, wh=
ich
> may confuse.
>=20
> Instead of using spear "->value" would it be possible to fetch the val=
ue
> just like object constants?
>=20
> print Suit::Clubs::value; // 'C'
> echo $var::value; // 'C'
>=20
> This mentally indicates by default that it's value is constant, simple=

> scalar value and read only!

We originally used a method in the first draft.  We changed it to a prop=
erty for three reasons.

1) There's lots of talk lately about immutable properties, so one way or=
 another "it's a property so I can write to it" is an assumption that wo=
n't hold much longer.
2) The property has to exist internally anyway, because under the hood i=
t's just a class with a property, so the name would still be reserved ei=
ther way.
3) Given 1 and 2, adding a method on top just adds some micro overhead f=
or the method call.

A constant-esque syntax wouldn't be possible because under the hood, the=
 cases are objects now, not classes.  We could put constants on Suit, bu=
t Suit::Clubs is an object, and objects can't have constants independent=
 of their class.

> 2. Regarding the Scalar Enums declaration syntax
>=20
> enum Suit: string {
>   case Hearts =3D 'H';
> }
>=20
> Would it make sense to move the part declaring enumeration value befor=
e
> enum name?
> I think it was put here to look similar to function return type, but I=
MHO
> it looks better and reads easier
> when moved before enum name:
>=20
> enum:string Suit {
>   case Hearts =3D 'H';
> }
>=20
> Leaving the space between enum name and bracket for further extensions=
 in
> future.
> What do you think?

That would be a very one-off syntax.  The colon-suffix is already establ=
ished in PHP, and i the same as the syntax used in Swift.  What you're d=
escribing looks a lot more like a generic.  Which... I suppose in some w=
ays this is if you squint really hard?  I don't have much of an argument=
 against it other than aesthetic.  I have no idea what the parser would =
do with it.

--Larry Garfield