Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112452
X-MailCleaner-return_path: brendt@stitcher.io
X-MailCleaner-sender_address: brendt@stitcher.io
X-MailCleaner-recipients: internals@lists.php.net
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 7 Dec 2020 11:24:28 +0100
References: <d1c4689e-9120-4e90-837c-a1b3eac63cd6@www.fastmail.com>
 <CAN2symh0kEQRa+1DxRAzJHrdqmQFP2xnjKGd1wmsfU_Lv9rH=A@mail.gmail.com>
 <32277b43-079d-4cd7-a159-8ad555096742@garfieldtech.com>
 <CAN2symgz-4BoLMUUyQMRXAzzCBB3nf+p160UJyB0H-LCFThXvw@mail.gmail.com>
 <31c9d66b-771a-35ed-1b11-c681bbcc02c3@gmail.com>
 <CAN2symjwms40cMu3kx44=iSNn5sZZ1jEGeKxfZmLZrQFjJQouQ@mail.gmail.com>
 <b6154319-5795-6022-dc3f-3d1c5484c81e@gmail.com>
To: Levi Morrison via internals <internals@lists.php.net>
In-Reply-To: <b6154319-5795-6022-dc3f-3d1c5484c81e@gmail.com>
Message-ID: <66A17C7A-2781-42A7-898B-309E8B59650B@stitcher.io>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-MailCleaner-TrustedIPs: Ok
Subject: Re: [PHP-DEV] [RFC] Enumerations
From: brendt@stitcher.io (Brent Roose)

Hi Larry and Ilja

It's great to see you're looking into enums, thanks! I have a few =
considerations from a userland point of view. I've been maintaining a =
userland enum implementation for a while now [1] so I think I share a =
thing or two about my experience.

- Scalar enums are spot on, exactly what I'd expect.
- Support with match is awesome, and I think makes it so that array key =
support isn't necessary.
- Others already addressed that serialization and deserialization would =
be a nice feature. A common use case is to store enums in a datastore of =
some kind, and it would be nice not having to make dedicated factories =
for them.
- The `case` syntax feels quirky. I assume it's because PHP wouldn't =
allow something like this:

```
enum Suit: string {
  Hearts =3D 'H';
  Diamonds =3D 'D';
  Clubs =3D 'C';
  Spades =3D 'S';
}
```

Finally, I've got one (rather large) concern about object enums, =
specifically with methods implemented on a per-enum basis. I did the =
same [2] when I first implemented my userland package. =46rom my =
research back then, I believe only Java [3] allowed this behaviour. If =
you've checked out that link, you've seen that value specific methods =
have been removed in v2. That's with good reason: they turned out to =
rather cumbersome to maintain and even a bit useless. Here's why:

- You example shows one method, the `color` one, which is still kind of =
manageable. If you allow enum methods though, you'll often end up with =
more than one method: `label`, `color`, `index`, `name`, `id`, are a few =
that come to mind. In the end an enum grows very large and unmanageable, =
with often lots of repeated code.
- Enum value methods actually are the state pattern [4] in disguise. One =
difference being that enums objects can't manage their own internal =
state, so they become less useful in applying the state pattern compared =
to using classes.

I think enums shouldn't aim to solve the state pattern. It's out of =
scope for what enums should do and their way of solving the state =
pattern will be worse in practice compared to using classes. I'd say it =
would be good to keep the defintion of enums in mind:

> "an enumerated type [=E2=80=A6] is a data type consisting of a set of =
named values called elements, members, enumeral, or enumerators of the =
type. The enumerator names are usually identifiers that behave as =
constants in the language." [5]

"Named values" and "constants" being the keywords here, there's no =
"behaviour" implemented by enum values, which is why only a small amount =
of languages allow this kind of functionality.

I realise enum objects might seem like a good idea to provide more =
value-specific functionality in a concise way, but let's compare =
per-value methods with a method on the base enum:

```
enum Suit implements Colorful {
  case Hearts {
    public function color(): string {
      return "Red";
    }
  }
=20
  case Diamonds {
    public function color(): string {
      return "Red";
    }
  }
=20
  case Clubs {
    public function color(): string {
      return "Black";
    }
  }
=20
  case Spades {
    public function color(): string {
      return "Black";
    }
  }
=20
  public function shape(): string {
    return "Rectangle";
  }
}
```

vs

```
enum Suit implements Colorful {
    case Hearts;
    case Diamonds;
    case Clubs;
    case Spades;

    public function color(): string {
        return match ($this) {
            Suit::Hearts, Suite::Diamonds =3D> "Red",
            Suit::Clubs, Suite::Spades =3D> "Black",
        }
    }
}
```

In summary:

- If you'd use enum objects for "simple functionality", I'd say `match` =
will always be the more concise way.
- If you'd use enum objects for handling complex state, you're better =
off using classes and properly implementing the state pattern.

I don't think enum objects should be a blocker, if people _really_ want =
it then fine. Based on my experience though, I'm rather sure that they =
won't be very useful, and would love to hear your opinion on the matter.

Kind regards
Brent

[1] https://github.com/spatie/enum
[2] https://github.com/spatie/enum/tree/v1#enum-specific-methods
[3] https://www.geeksforgeeks.org/enum-in-java/
[4] https://en.wikipedia.org/wiki/State_pattern
[5] https://en.wikipedia.org/wiki/Enumerated_type

> On 7 Dec 2020, at 10:30, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On 07/12/2020 01:00, Paul Crovella wrote:
>> Instance state being global is a well-known problem with singletons.
>> Maybe don't use singletons then. Or simply document them as was done
>> in the RFC. I'd prefer the former since singletons don't seem to buy
>> much here but problems, though maybe I'm missing something.
>=20
>=20
> Yes, I think you are missing something - or maybe I am, because I =
honestly can't picture what it would look like for enums *not* to be =
singletons.
>=20
> Would Suit::Hearts be a constructor, producing a new instance each =
time, each with its own state? Would we then overload =3D=3D=3D, so that =
Suit::Hearts =3D=3D=3D Suit::Hearts was still true somehow?
>=20
>=20
> > In any case why is static state being (kinda sorta) restricted along =
with it?
>=20
>=20
> On the face of it, I agree, static properties could be supported. But =
looking at the details of the current proposal, it might actually take =
some thought to make them feel natural. As I understand it, each case =
acts like a sub-class, which is useful for over-riding instance methods, =
but would mean a static property would be defined separately on each =
case:
>=20
> enum Suit {
>     static $data;
>     case Hearts;
>     case Spades;
>     case Clubs;
>     case Diamonds;
> }
>=20
> Suit::$data =3D 42;
> $mySuit =3D Suit::Hearts;
> var_dump($mySuit::$data); // will not print 42, because =
Suit::Hearts::$data is a different property
>=20
>=20
> As Pierre says, the idea of backing enums onto objects is mostly an =
implementation detail; their fundamental design is based on how enums =
are generally used, and implemented in other languages.
>=20
> Rather than "objects which are a bit enum-like", it might be useful to =
frame them as "enums which are a bit object-like". The primary =
consistency needs to be with what people will expect an enum to do.
>=20
> Backing them onto objects makes it easy to add on any object-like =
behaviour that feels useful, but once we've added it, it's much harder =
to remove or change if we realise it's causing problems for users, or =
getting in the way of other features.
>=20
> That's why I was asking if you had use cases in mind, because I was =
starting from that position: assume they have *no* features, and add the =
ones we think are necessary and achievable.
>=20
>=20
> Regards,
>=20
> --=20
> Rowan Tommins (n=C3=A9 Collins)
> [IMSoP]
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20