Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112901
User-Agent: Cyrus-JMAP/3.5.0-alpha0-45-g4839256-fm-20210104.001-g48392560
Mime-Version: 1.0
Message-ID: <e7dca4f2-037a-4dd1-9816-6b65cb0c6b80@www.fastmail.com>
In-Reply-To: <b7f68e05-b45f-92a8-a333-bb7d008f4407@processus.org>
References: <deff4418-5c66-4f19-ba25-b2c267e8b53f@www.fastmail.com>
 <b7f68e05-b45f-92a8-a333-bb7d008f4407@processus.org>
Date: Fri, 15 Jan 2021 10:54:36 -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 Fri, Jan 15, 2021, at 9:55 AM, Pierre R. wrote:
> Le 10/01/2021 =C3=A0 22:27, Larry Garfield a =C3=A9crit=C2=A0:
> > This is a little tangent from the Enums RFC, but I want to flag it b=
ecause it it's the sort of in-passing decision that could have far-reach=
ing implications, so shouldn't be done implicitly.
> >
> > At the moment, the Enum RFC for scalar enums includes two methods:
> >
> > public function has(string $name): bool
> >
> > public function from(string $name): self throws ValueError
> >
> > Nikita raised the point that has() seems kinda pointless as it would=
 only ever be used to wrap a possibly-unsafe from() call.  (In most othe=
r cases, calling cases() would be more useful or at least equally useful=
.)  One of the proposed alternatives was the following:
> >
> > public function from(string $name): self throws ValueError
> >
> > public function tryFrom(string $name): ?self
> >
> > The "a method that begins with try is nullable, so watch out" idiom =
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 the nul=
l coalesce operator to allow for default values, making a valueOrDefault=
() method unnecessary.
> >
> > $order =3D SortOrder::tryFrom($input) ?? SortOrder::Asc;
> >
> > I'm not opposed to following that pattern here; it would allow both =
a "hard fail" and "soft fail" variant of the operation.  However, as not=
ed that idiom has never appeared in PHP before that I'm aware.  If we ad=
opt it here, that means it will either start to spread and become a more=
 common PHP idiom over time, OR it won't spread and Enums will have this=
 weird one-off naming convention for a nullable method.  The former woul=
d, of course, be considerably preferable to the latter.
> >
> > So, explicit decision time: Are we OK with introducing that idiom, a=
nd then following it consistently in the future in similar situations?  =
(viz, tryX() means nullable, and no-try means not nullable.)  I'm good w=
ith it if the consensus is good with it, but I want to see what the cons=
ensus is first.
>=20
> I'm OK with the tryBar(): ?Foo pattern, but my preference goes over ju=
st=20
> bar(): ?Foo, as long as API are explicitly typed and correctly documen=
ted.

Well, the concern is that we also want to have a from(): Foo throws Valu=
eError version, but both cannot be called from().

The possible patterns are:

Interface:
Suit::from(string): ?self

Usage:=20
$s =3D Suit::from($var) ?? Suit::SomeDefault;

Interface:
Suit::from(string): self throws ValueError
Suit::has(string): bool

Usage:
if (Suit::has($var)) {
  $s =3D Suit::from($var);
}

Technically, one could create the second from the first more easily than=
 vice versa, but both could implement each other.

try {
  $s =3D Suit::from($var);
}
catch (ValueError) {
  $s =3D Suit::SomeDefault;
}

// or

$s=3D Suit::from($var) ?? throw new ValueError();

While the nullable return ?? is very appealing, we know from experience =
that most people don't think to check the null case, leading to unhelpfu=
l "method called on non object" errors 6 months later when someone passe=
s in bad data.  An Optional/Maybe type is the ideal solution as that for=
ces people to account for that possibility, but we don't have those yet.=
  (Enums are a step toward being able to build them cleanly.)  A thrown =
exception is next, although nothing forces people to include the try-cat=
ch so they could forget that, too.  At least static analyzers tend to wa=
rn you about it.  Nullable is least likely to get handled in practice, e=
ven if the resulting code may, in all honestly, look the cleanest if you=
're OK with ??.

Offering both exception and nullable variants is a compromise option, bu=
t that requires disambiguating the names somehow.  TryX -> nullable is t=
he least-bad suggestion so far, IMO.

I'm still not sure of how we want to proceed. :-/

> I will not fight against or for any or another solution, as long as th=
e=20
> convention remains the same for everything.
>=20
> Larry, I think your proposal is missing something: if a convention=20
> emerge, it should be documented as such, and be considered as a law fo=
r=20
> subsequent language / API addition, the real question, IMHO, is : Are=20=

> people OK with writing naming and design conventions by law in PHP cor=
e ?
>=20
> For that matters, I'm OK, this would avoid many bikesheds in the futur=
e:=20
> this is the law, and the law says, name it tryX(), no more useless=20
> votes, no more flavor-oriented flame wars on naming :)

While such a formal convention would be nice, that's a separate fight, a=
nd the last time I picked that fight (https://wiki.php.net/rfc/php_names=
pace_policy) we lost. :-)  For now I just want to keep enums de facto co=
nsistent.

--Larry Garfield