On Tue, Jul 18, 2023 at 8:05 AM Robert Landers <landers.rob...@gmail.com> wrote:
> On Tue, Jul 18, 2023 at 3:18 PM Olle Härstedt <olleharst...@gmail.com> > wrote: > > > > 2023-07-18 14:48 GMT+02:00, someniatko <somenia...@gmail.com>: > > > I am glad this topic arose! I was also planning to write on this topic > to > > > the internals mailing list, but have abandoned this idea, because I > feel it > > > might be inconvenient for the real active PHP developers on the list to > > > receive too many emails from the people which don't actively > participate in > > > the development itself. > > > > > > My interest in the pipe operator might seem a little non-standard - > > > basically what I'd really want to see is a **nullable** pipe operator! > > > > > > There is a popular library github.com/schmittjoh/php-option, which > has 250 > > > MILLION installations. Basically what it provides is a class-wrapper > of a > > > value of lack thereof: it's either `Some<Type>` or `None`. I also > maintain > > > a similar library > https://packagist.org/packages/someniatko/result-type > > > which fixes some shortcomings of the original one related to the static > > > analysis, but this is another story. Basically what the stats tell us > is > > > that such stuff is popular among the PHP community. > > > > > > In my eyes, it is actually semantically equivalent to the nullable PHP > > > types: `?Type`. And some operations provided by the lib, are actually > > > covered by PHP itself, which has multiple null-friendly operators: > > > `$option->getOrElse($defaultVal)` --> `$nullable ?? $defaultVal` > > > `$option->isEmpty()` --> `$nullable === null` > > > `$option->getOrThrow(new \Exception('blah'))` --> `$nullable ?? throw > new > > > \Exception('blah')` > > > > > > I'd like to use the arguably "more idiomatic" native PHP nullables, > rather > > > than a foreign-feeling userspace construct, if they were more > convenient. > > > > > > But there is a very important operation, `map()`, which is > unfortunately > > > not covered by the native PHP, which is `Option::map()`, and here is a > > > real-world example: > > > ``` > > > return $repository->getById($idFromHttpRequest) > > > ->map($serializer->serializeToJson(...)) // only executes when the > > > Option is Some, not None > > > ->map(fn (string $json) => new Response(status: 200, content: > $json)) > > > ->getOrElse(new Response(status: 404)); > > > ``` > > > > Ehm, wouldn't that be the same as a Pipe class that's configured to > > stop on null? > > > > public function getThing($id) { > > return new Pipe( > > $this->getData(...), > > $this->serializeData(...), > > $this->mapToResponse(...) > > ) > > ->stopOnEmpty() > > ->from($id) > > ->run(); > > } > > > > Wait, are you using map() for arrays or not? Looks like not. > > > > Olle > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > I might be venting, but, I wish the operators RFC had passed... > I don't think I will re-propose it with the current set of voters tbh. The main people who contribute to the Zend folder (the core engine/compiler parts) were highly skeptical of it, with at least two telling me flat out that they would vote no even on a hypothetical perfect feature design. Very few contributors actually touch large parts of that area of the engine, so most voters tend to take the opinions of those 5-6 voters very seriously on such proposals. As I don't think it's possible for me to convince those 5-6 people, I don't think it would be a good idea to re-propose, because even if I did get a 2/3 vote on it, I feel like the people most responsible for helping me maintain the feature would not be very happy/willing to do so, and that would probably harm the PHP project in other ways. Jordan
