Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112852
User-Agent: Cyrus-JMAP/3.5.0-alpha0-45-g4839256-fm-20210104.001-g48392560
Mime-Version: 1.0
Message-ID: <5a75eeed-7034-4771-be28-36323e845157@www.fastmail.com>
In-Reply-To: <1183F48B-57BB-4CBE-8474-CF1D7DFD7F6E@benramsey.com>
References: <deff4418-5c66-4f19-ba25-b2c267e8b53f@www.fastmail.com>
 <cmu-lmtpd-1237368-1610318405-0@sloti26t05>
 <fde16316-6e24-4735-b1dc-f2aad6c91ef5@www.fastmail.com>
 <490416F4-7E2F-454F-A317-43212CA6C2D1@benramsey.com>
 <28f44744-4dc5-4cb8-8751-6b66386119fa@www.fastmail.com>
 <26074258-B6B5-40EA-A043-E3FAD1FB5365@newclarity.net>
 <1183F48B-57BB-4CBE-8474-CF1D7DFD7F6E@benramsey.com>
Date: Tue, 12 Jan 2021 10:35:06 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] "TryX" idom for Enumerations
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Jan 12, 2021, at 10:13 AM, Ben Ramsey wrote:
> > On Jan 11, 2021, at 19:09, Mike Schinkel <mike@newclarity.net> wrote=
:
> >=20
> >> On Jan 11, 2021, at 6:52 PM, Larry Garfield <larry@garfieldtech.com=
> wrote:
> >>=20
> >> On Mon, Jan 11, 2021, at 2:27 PM, Ben Ramsey wrote:
> >>>> On Jan 10, 2021, at 20:09, Larry Garfield <larry@garfieldtech.com=
> wrote:
> >>>>=20
> >>>> On Sun, Jan 10, 2021, at 4:40 PM, Mark Randall wrote:
> >>>>> On 10/01/2021 21:27, Larry Garfield wrote:
> >>>>>> The "a method that begins with try is nullable, so watch out" i=
diom is present in C# and Rust, but to my knowledge has never existed in=
 PHP.  That doesn't make it bad; it actually combines quite well with th=
e null coalesce operator to allow for default values, making a valueOrDe=
fault() method unnecessary.
> >>=20
> >>=20
> >>> I have no problem introducing this idiom (or similar). In fact, I =
welcome it.
> >>>=20
> >>> In userland, the same concept is often achieved with methods like
> >>> `fromOrNull()`, and as Mark points out, the word =E2=80=9Ctry=E2=80=
=9D makes me think
> >>> the method should throw an exception if it fails. I=E2=80=99m not =
advocating
> >>> for `xOrNull()`, though, since I think that smacks of Hungarian
> >>> notation, but maybe we can come up with something that is a more
> >>> PHP-ish name. ;-)
> >>>=20
> >>> =E2=80=9CThere are two hard things in computer science: cache inva=
lidation,
> >>> naming things, and off-by-one errors.=E2=80=9D --Phil Karlton
> >>>=20
> >>> Cheers,
> >>> Ben
> >>=20
> >> Do you have a suggestion for a better, more PHP-ish naming conventi=
on?
> >=20
> > maybeFrom()?
>=20
>=20
> I think a `maybeX()` idiom is better, though it might be confusing to=20=

> those familiar with functional programming languages that have a=20
> `Maybe` data type.
>=20
> If we had generics, we could introduce a `Maybe` class, and these=20
> methods could return `Maybe<self>`, for example. That said, maybe=20
> `?self` is effectively the same thing?
>=20
> For me, `maybeX()` is great, but I=E2=80=99d like to hear any=20
> objections/suggestions from others.

The potential confusion with a Maybe monad type is my primary concern wi=
th that option, especially since being able to define a Maybe type is pa=
rt of what Ilija and I are working toward with Enums and then ADTs. :-) =
 (Like, literally, the potential for that is how he got me to join him o=
n this project...)

: ?self is not quite a Maybe type; it's somewhat similar in net effect, =
but a Maybe type forces the caller to then check to see if it's null and=
 unwrap it.  A nullable return will happily work fine without any error =
handling... until it fatally doesn't.  A Maybe type is essentially what =
Swift does in this case.  We can't do the same here due to chicken-or-eg=
g problems.

My other issue with maybe is that it's a bit long in comparison, but tha=
t's somewhat secondary.  "Maybe" has enough prior art that it would be e=
ven more confusing than "try," I feel.

--Larry Garfield