> On Dec 9, 2020, at 2:06 PM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
>
> On 09/12/2020 18:47, Mike Schinkel wrote:
>> 1. Will enum methods be idempotent?
>>
>> If not, shouldn't they be?
>
>
> 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 {
case Morning;
case Afternoon;
case Evening;
case Night;
public static function now() {
$now = intval(date('H',time()));
return match(true) {
$now < 8 => static::Night,
$now < 12 => static::Morning,
$now < 18 => static::Afternoon,
default => static::Evening,
};
}
}
[1]
https://docs.microsoft.com/en-us/sql/relational-databases/user-defined-functions/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.
>
> 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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
