2023-07-18 17:13 GMT+02:00, Larry Garfield <la...@garfieldtech.com>: > On Tue, Jul 18, 2023, at 1:05 PM, Olle Härstedt 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'd just like to mention that the Option type comes from FP and it's >> not necessarily needed in PHP-land where we have flow-sensitive type >> checkers like Psalm (a nullable type `?int` or such is refined to just >> `int` after a null check). Flow-sensitive type-checking was not >> invented when the Option type was first created, so adding it to PHP >> is basically stepping back in time, from my point of view. > > As I've written before[1], there's a lot of overlap in different > error-flow-control options. PHP at the moment leans heavily on the "null is > error and build tooling around that" approach, which has its pros (mainly > simplicity) and cons (lack of information). That mostly obviates the need > for a Maybe type, but not entirely. Right now, there is no "null pipeline" > option in the language like someniako is describing. > > In some sense, that's also trivial to do in user-space[2], which leads > easily to > > $foo > |> maybe(bar(...)) > |> maybe(baz(...)) > |> maybe(beep(...)); > > Which isn't terrible, but also isn't ideal. I don't think I'd oppose a > nullsafe pipe if there's interest (though again, we need interest in pipes > in general first). > > However, that runs into the related problem that Maybe is... the weaker way > of handling error context. In most cases I prefer a Result/Either type, > which doesn't map cleanly to null handling. That could be done as a > user-space monad (as above, with just a class and method or a magic method > and dedicated operator). Doing it more natively would require deeper > language hooks. For instance, Rust has the ? suffix on any expression, > which means "if this evaluates to an Error case Result, just return that > Result." That wouldn't fit well in PHP, though. > > As I noted in [1], one option would be to allow an object to flag itself as > an error object, and then null-check operators would treat that as null. So > given $result = foo($a)->bar(), if foo() returns an error object then > $result is assigned to that error object and bar() is never called. I'm > still not sure if I like that approach myself, but am open to hear what > others think. > > To get back on topic, I do think a pipe operator and concat operator are > valuable in their own right, and have ample use cases even without mixing in > monads or nullables or things like that. We should add them. We can > consider adding more robust branching options as well, (be that >>=, ?|>, or > something else), but be aware that beyond the very trivial case that will > necessarily involve user-space code for many use cases and we'll need to > support that. (Which basically comes down to >>= and making monadic classes > easier to work with, but also runs into the generics problem, and that's its > own mess.) > > [1] https://peakd.com/hive-168588/@crell/much-ado-about-null > [2] https://github.com/Crell/fp/blob/master/src/composition.php#L39 > > --Larry Garfield >
Any comment on a pipe (or piped process) as a first-class value? When you use |> the functions are immediately applied, which might not be what you want. You can lazify it by wrapping it in a lambda, but I think that decreases the value of the pipe concept in itself. One strength is the ability to split the decision about what to glue together from the decision on how to execute it. You kinda get some light-weight metaprogramming ability that way. Well i guess such a pipe-concept is pretty far removed from the simple pipe operator. :) And also already possible with existing OOP concepts, callable classes, and now the (...) syntax. Olle -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
