Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112480
User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3
Mime-Version: 1.0
Message-ID: <11d829df-7e61-497d-bfd6-0f74045928ab@www.fastmail.com>
In-Reply-To: <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>
 <CE365AC5-B850-429E-B346-DB34A1180FE8@newclarity.net>
Date: Wed, 09 Dec 2020 18:23:57 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Enumerations
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Dec 9, 2020, at 2:03 PM, Mike Schinkel wrote:


> > 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

What you're describing is memoization.  Memoization is only safe on idempotent functions.  Please do not confuse the two terms, as they mean very different things.

However, as long as global variables exist in the language and there are file IO operations defined, we cannot guarantee that a given method is idempotent and thus safely memoizable.  Saying "well this function/method really should be idempotent if you're doing it right" (even when correct) is insufficient justification for blindly memoizing it.  That's true regardless of whether or not the method in question is on an enum.

Having a way for developers to flag a function as safe to memoize would be helpful, but is a completely different topic from Enums.

Forbidding enum-bound state is as close to guaranteed idempotence as PHP allows, which is what the current RFC does.

--Larry Garfield