Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112477
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
In-Reply-To: <1150805a-44b0-af7e-d54b-6082fd23a63e@gmail.com>
Date: Wed, 9 Dec 2020 15:03:11 -0500
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <CE365AC5-B850-429E-B346-DB34A1180FE8@newclarity.net>
References: <d1c4689e-9120-4e90-837c-a1b3eac63cd6@www.fastmail.com>
 <DA260CE1-8523-4737-A5CE-052160846E79@newclarity.net>
 <1150805a-44b0-af7e-d54b-6082fd23a63e@gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Enumerations
From: mike@newclarity.net (Mike Schinkel)

> On Dec 9, 2020, at 2:06 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On 09/12/2020 18:47, Mike Schinkel wrote:
>> 1. Will enum methods be idempotent?
>>=20
>> If not, shouldn't they be?
>=20
>=20
> Can you clarify what you mean here?

For a given parameter set the method would always return the same value. =
Note I am not suggesting that values would be fixed across different =
executions, only within a given execution.

Said another way, idempotent and deterministic[1] are effectively =
equivalent.

Taking this example the now() method would not be idempotent nor =
deterministic:

enum DayParts { =20
    case Morning;
    case Afternoon;
    case Evening;
    case Night;
    public static function now() {
        $now =3D intval(date('H',time()));
        return match(true) {
            $now < 8 =3D> static::Night,
            $now < 12 =3D> static::Morning,
            $now < 18 =3D> static::Afternoon,
            default =3D> static::Evening,
        };
    }
}

[1] =
https://docs.microsoft.com/en-us/sql/relational-databases/user-defined-fun=
ctions/deterministic-and-nondeterministic-functions

> The only meaningful question I can think of is "can they change the =
object's state?" That's mostly answered in the RFC, most notably by =
specifying that enums may not have instance properties, to avoid them =
having any state to change.
>=20
> Unless I'm missing something, trying to define "idempotence" or "pure =
functions" any more strictly than that would surely be a massive project =
in itself - for a start, you'd need a whitelist of all built-in =
operations which were side-effect free (i.e. no file writes, =
configuration changes, output, etc, etc).

I do not believe it should be a massive project. I believe it could be =
implemented with a simple map that takes a hash of the input parameters =
and maps to their return value.  For idempotency this value should be =
calculated the first time the method is called.=20

After the first call every subsequent call would hash the input =
parameters, lookup the pre-calculated value from the map, and the just =
return it without re-executing any code in the method except for the =
return statement (I am considering of the desire to set a breakpoint in =
XDEBUG on return for all accesses, not just the first.)

The one potential concern is if the number of potential input =
permutations is large it could eat a lot of memory if the app actually =
used a lot of them.  But then that is true on any use of memory in PHP, =
so if it became a problem for a developer I think it should be on them =
to rearchitect their solution to avoid using too much memory.

This is an important question to answer *now* because IF the answer to =
idempotency  is "no" then restricting it a later to be idempotent would =
require accepting a BC break.  But if the answer is YES, the restriction =
could always be relaxed in a future version if that ever made sense.

-Mike=