On Sat, Apr 24, 2021, at 2:55 PM, Olle Härstedt wrote:
> 2021-04-24 21:51 GMT+02:00, Marco Pivetta <ocramius@gmail.com>:
> > On Sat, Apr 24, 2021, 21:44 Olle Härstedt <olleharstedt@gmail.com> wrote:
> >
> >> 2021-04-24 17:59 GMT+02:00, Saif Eddin Gmati <azjezz@void.tn>:
> >> >> Doesn't this violate the principle: It should be possible to add new
> >> >> features without touching old code?
> >> >
> >> > This depends on which syntax is picked, both `for` and attribute syntax
> >> will
> >> > be completely BC.
> >>
> >> I'm not talking about BC, but the maintainability of the new feature
> >> itself. For the shape example, you'd need to edit the original file
> >> for each new shape you add, which is detrimental for maintainability
> >> and scalability. So what's a good use-case?
> >>
> >
> > The main use-case of sealed types is being able to declare total functions
> > around them.
>
> What is "total function" in your discourse? :) Can you find a more
> concrete example? Preferably one that's relevant for web site/app
> development. Shapes is a bit too generic, I think.
>
> Olle
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.
In practice, I think all of the use cases for sealed classes are ADT-esque. As I noted before, combining sealed classes with Nikita's new-in-expressions RFC would allow for this (also using my short-functions RFC for this example, although that's a nice-to-have):
sealed class Maybe permits Some, None {
public const None = new None();
static public function Some($x) => new Some($x);
public function value() => throw new NotFoundException();
public function bind(callable $c) => static::None;
}
final class None extends Maybe {}
final class Some extends Maybe {
private $val;
private function __construct($x) { $this->val = $x; }
public function value() => $this->val;
public function bind(callable $c) => new static($c($this->val));
}
Now if you have an instance of Maybe, you can be absolutely guaranteed that it's either an instance of Some or of None. It's very similar to the guarantee you get for enumerations, that you will have one of a fixed set of dev-defined values and don't need to worry about any other case. You handle None, you handle Some, and now your function is a total function over its Maybe parameter.
There are assorted other cases along those lines.
That gets you essentially the same functionality by a different route as what the tagged unions RFC (https://wiki.php.net/rfc/tagged_unions) proposes:
enum Maybe {
case None {
public function bind(callable $f) => $this;
}
};
case Some(private mixed $value) {
public function bind(callable $f): Maybe => $f($this->value);
};
public function value(): mixed => $this instanceof None
? throw new Exception()
: $this->val;
}
Or to use another example from the tagged unions RFC:
enum Distance {
case Kilometers(public int $km);
case Miles(public int $miles);
}
vs:
sealed interface Distance permits Kilometers, Miles { ... }
class Kilometers implements Distance {
public function __construct(public int $km) {}
}
class Miles implements Distance {
public function __construct(public int $miles) {}
}
In either case, a function can now operate on distance and know that it's dealing with a value in miles OR in kilometers, but it doesn't have to worry about yards, furlongs, or light-years. Combined with a pattern-matching operator (which Ilija is working on here: https://wiki.php.net/rfc/pattern-matching), it would make it possible to combine ADTs/sealed classes with a match() statement and know that you've covered every possible situation with a trivial amount of code.
Enums, Sealed classes, and tagged unions all play in the same logical space, of allowing the developer to more precisely define their problem space and data model in a way that "makes invalid states unrepresentable",,and thus eliminates a large amount of error handling resulting in code that is harder if not impossible to "get wrong."
I think it's clear that there's desire to have such capability, but the specifics of how we get there are not as clear-cut. For instance, as currently envisioned tagged unions would extend enums, and as they're a dedicated language construct we can build in read-only properties. Sealed classes wouldn't be able to do that... however, if we also added asymmetric visibility to properties or Nikita's proposed property accessors, a class could itself force a property to be public-read-only. At that point, you would be able to implement the entire tagged-union RFC's functionality by combining sealed classes, read-only properties, and pattern matching. It would just have a less specific-to-the-use-case syntax, which could be good or bad depending on your point of view.
I hope that clears up the problem space this RFC is working in. Whether we want to achieve that functionality through enum-based tagged unions or through sealed classes, new-in-expression, and read-only properties is an open question, and I'm not entirely sure yet which I favor. I can see pros and cons to both approaches; I just know I really want at least one of them, in 8.1 if at all possible. :-)
--Larry Garfield
