Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120837
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-531-gfdfa13a06d-fm-20230703.001-gfdfa13a0
Mime-Version: 1.0
Message-ID: <51a97131-f64e-4939-9339-24e70873fe32@app.fastmail.com>
In-Reply-To: 
 <CAJpLVh3BXQ4rB_5WZK7DopesFgwQ2K5xMD_EgWRQ0-Zd4BF_5A@mail.gmail.com>
References: 
 <CAOfzkkxrQOje274RMUW8kv13vBmtNSNd_D9Bq_SJeDEBVA8i7Q@mail.gmail.com>
 <CAJpLVh1hhd=zxSz+T4eZdd7eBD-40muU81eFwhmh3e0n7VGwyQ@mail.gmail.com>
 <8055b366-32f1-4d2c-85d0-0cf665e6c8d3@app.fastmail.com>
 <CABAhh3FjjwyZjrpzrES6E1kbRz_czg64-CRxtKw-jkY5JzGYeA@mail.gmail.com>
 <CAJpLVh3BXQ4rB_5WZK7DopesFgwQ2K5xMD_EgWRQ0-Zd4BF_5A@mail.gmail.com>
Date: Tue, 18 Jul 2023 15:13:22 +0000
To: =?UTF-8?Q?Olle_H=C3=A4rstedt?= <olleharstedt@gmail.com>,
 someniatko <someniatko@gmail.com>
Cc: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] pipes, scalar objects and on?
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Jul 18, 2023, at 1:05 PM, Olle H=C3=A4rstedt wrote:
> 2023-07-18 14:48 GMT+02:00, someniatko <someniatko@gmail.com>:
>> I am glad this topic arose! I was also planning to write on this topi=
c to
>> the internals mailing list, but have abandoned this idea, because I f=
eel 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 particip=
ate 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 ha=
s 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-f=
low-control options.  PHP at the moment leans heavily on the "null is er=
ror and build tooling around that" approach, which has its pros (mainly =
simplicity) and cons (lack of information).  That mostly obviates the ne=
ed for a Maybe type, but not entirely.  Right now, there is no "null pip=
eline" option in the language like someniako is describing.

In some sense, that's also trivial to do in user-space[2], which leads e=
asily to

$foo=20
  |> maybe(bar(...))=20
  |> 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 pip=
es 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 t=
ype, 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 me=
thod and dedicated operator).  Doing it more natively would require deep=
er language hooks.  For instance, Rust has the ? suffix on any expressio=
n, which means "if this evaluates to an Error case Result, just return t=
hat 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 n=
ull.  So given $result =3D foo($a)->bar(), if foo() returns an error obj=
ect then $result is assigned to that error object and bar() is never cal=
led.  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 mixi=
ng in monads or nullables or things like that.  We should add them.  We =
can consider adding more robust branching options as well, (be that >>=3D=
, ?|>, or something else), but be aware that beyond the very trivial cas=
e that will necessarily involve user-space code for many use cases and w=
e'll need to support that.  (Which basically comes down to >>=3D and mak=
ing 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