On Sun, Apr 25, 2021, at 9:48 AM, Mike Schinkel wrote: > > A total function is a function that is defined over the entire domain of > > its inputs. For example, addition is a total function over integers, > > because for every possible pair of integers you pass to it there is a > > logical return value. However, square root is not a total function over > > integers because there are some integers you pass it for which there is not > > representable return value. (Negative numbers, unless you get into > > imaginary numbers which PHP doesn't support.) In those cases, you have to > > throw an exception or return an error code or similar. > > > > For a more typical PHP example, getUser(int $id) is not a total function, > > unless you have PHP_MAX_INT user objects defined in your database. If you > > pass an int that does not correspond to a defined user, you now have to > > deal with "user not found" error handling. getUser() is not a total > > function. getUsers(array $criteria), however, arguably is, because it's > > logical and reasonable to map all not-found cases to an empty > > array/collection, which doesn't require any special error handling.
> Nothing I am about to write is meant to question the value of total > functions, but can you speak to the ramifications of a developer using > a library with a total function that returns miles or kilometers in > (say) version 2.0, along with the assumed guarantees of said function, > but then in version 3.0 the developer adds furlongs as a unit of > measure? > > Yes going from 2.0 to 3.0 is a breaking change per semver, but it > doesn't feel like it had to be had the application developer not made > the total function assumption. > > -Mike It would be a breaking change, because you're changing the definition of the problem space. Just as if you added a new option to an enum, or changed an Interface to have a method return iterable instead of array. If you change the definition of the data model, that's a breaking change and all bets are off anyway. Whether or not making it sealed in the first place was a good call is going to vary widely depending on the situation. They're really not appropriate for service objects, where by design you could have an infinite number of possible PaymentGateway objects. They're much more applicable for data objects that represent a finite number of business-relevant situations, where changing them means the problem space is changing *anyway* so changing code around the problem space is going to happen anyway. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
