Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112990
MIME-Version: 1.0
References: <eadd4a32-a05b-463b-a91f-a5d353c577b2@www.fastmail.com> <8f17a7b3-2488-461f-9756-d675b1dc0981@www.fastmail.com>
In-Reply-To: <8f17a7b3-2488-461f-9756-d675b1dc0981@www.fastmail.com>
Date: Mon, 25 Jan 2021 17:04:32 +0000
Message-ID: <CAFPFaM+8rd-WyfmS2XeonK7wcfxA0Ss=yuRjJS-SMuGF29SwtQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c2ea2805b9bc88bc"
Subject: Re: [PHP-DEV] [RFC] Enumerations, Round 2
From: george.banyard@gmail.com ("G. P. B.")

--000000000000c2ea2805b9bc88bc
Content-Type: text/plain; charset="UTF-8"

On Mon, 25 Jan 2021 at 02:29, Larry Garfield <larry@garfieldtech.com> wrote:

> Aside from some nitpicking around reflection and possibly fiddling with
> the naming of "Scalar Enum" et al, we're closing in on the final version.
> It will probably go to a vote in the not too distant future.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Most of this has already been communicated off list but I ought to make my
opinions on the proposal somewhat "official".

Although I do think we need enums backed into PHP, I'm really not keen on
piggy backing on objects.
I'm also aware that this would be a larger undertaking as using objects as
one would need to rewrite part of the logic objects use.
However, looking at how much of the objectness needs to be blocked and/or
modified (traits, final, no properties, etc.), IMHO, points towards a new
zval structure instead of reusing objects, at least for the simple cases as
a simple enumeration set or a scalar backed enumeration set which don't
need any methods.
Moreover, the implementation details of it leak quite a lot and I'm not
really a fan of having the reflection class of enum extend the class one.

My reasoning is that, albeit extremely clunky, one can already achieve the
kind of enumeration proposed here in userland, in a type safe fashion, in
PHP 8.0 by using union types:

final class Heart {}
final class Clubs {}
final class Spades {}
final class Diamond {}
final class Suit {
    public function __construct(private Heart|Clubs|Spades|Diamond $value)
{}
    public function value() { return $this->value; }
}

This form is basically reducing an ADT to an enumeration, and in any case
introducing additional syntax to alleviate the verbosity of this is a
separate concern.
(to see this somewhat in action I've written some slides for small
university talk which demonstrates how it can be used [1][2]).

The final concern, which might be non-existent as there is no mention of it
in the RFC, is OPcache.
My understanding of OPcache is fairly limited, but IIRC caching and
optimizing things around objects is extremely complicated if not at all
impossible, wouldn't this rather severe limitation also apply to enums,
even for basic lists?
Or are all the objectness restrictions placed on enums sufficient to make
this a non-issue?

As such, unless convinced otherwise, I don't think I will personally
support this proposal.

Best regards,

George P. Banyard

[1]
https://slides.com/girgias/reflection-algebraic-data-types-for-mortals#/5/5
[2]
https://slides.com/girgias/reflection-algebraic-data-types-for-mortals#/5/6

--000000000000c2ea2805b9bc88bc--