Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125291
Feedback-ID: id5114917:Fastmail
Date: Mon, 26 Aug 2024 21:34:50 +0100
To: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Default expression
User-Agent: K-9 Mail for Android
In-Reply-To: <D461460B-E248-4FEB-8375-55239729A633@newclarity.net>
References: <99846F78-38F8-4549-B0A6-6310933AA78D@newclarity.net> <0B974990-05FE-4C46-9C2B-3C243C7E8E81@getmailspring.com> <07E4ABD5-B9CE-47FA-BD9E-E42A82CFC737@newclarity.net> <4c3bc918-3aec-4cc5-b342-0924e10949bc@app.fastmail.com> <D461460B-E248-4FEB-8375-55239729A633@newclarity.net>
Message-ID: <BE829519-2FC3-4564-BE47-1E2764546D5B@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 26 August 2024 20:27:59 BST, Mike Schinkel <mike@newclarity=2Enet> wrot=
e:
>So, nullable is an equivalent to the union-type concern my discussion wit=
h John Coggeshall uncovered, correct?=20

It's not really anything to do with nulls, or unions=2E It's somewhat rela=
ted to "contravariance of input": that it should always be safe to substitu=
te a function that accepts a wider range of input=2E If you have an input "=
DateTime $d", it's always safe to substitute (in a subclass, or a later ver=
sion) "DateTimeInterface $d", or "?DateTime $d", or "DateTime|string $d", o=
r any combination of the above=2E=20

And right now, while doing so, you can safely change the default value to =
any value that is valid for the new input type, because all the caller know=
s is that the parameter is optional=2E=20

For instance, "DateTime $d=3Dnew DateTime('now')" might become "DateTimeIn=
terface $d=3Dnew DateTimeImmutable('now')"=2E Or maybe one subclass has "Da=
teTimeInterface $d=3Dnew DateTimeImmutable('now')" and another has "DateTim=
eInterface $d=3Dnew DateTime('now')"=2E



>Now consider the following, assuming the RFC passed but with an added req=
uirement that `match()` be used exhaustively for nullable parameters (shown=
) or parameters type hinted with unions (not shown):
>
>$configSource =3D new ConfigSource(default,match(default){=20
>	NULL=3D>new ConfigSource->getDefaultHttpClient()->withRequestTimeoutSecs=
(5),
>	default=3D>default->withRequestTimeoutSecs(5)
>})
>
>Ignoring that this expression is overly complex, if covering all "types" =
 would be a requirement in the RFC =E2=80=94 where `NULL` is a type here fo=
r purposes of this analysis =E2=80=94can you identify another breaking chan=
ge if the RFC passed?

Certainly=2E A new version of the library can change the parameter to "?Ne=
tworkClientInterface $httpClient=3Dnew WebSovketClient"=2E (The name kept t=
he same because named parameters mean callers may be relying on it=2E)

As written, it's also entirely pointless, because you've called getDefault=
Client(), whose entire purpose is to be a stable public API which you can r=
ely on for that purpose, rather than peeking into implementation details=2E



>I did not say there was _no_ distinction, I said that we cannot be *certa=
in* the values are indeed private=2E Subtle difference I admit, but there _=
is_ a difference=2E :-)


This is true only in the extremely pedantic sense that "we can't be certai=
n that private properties are private"=2E It's not at all relevant to my ar=
gument, which is that right now, the language treats default values as part=
 of the implementation, not part of the public API=2E


>P=2ES=2E The more I think about this, the more I think that the default v=
alue *should* be a formal part of the function signature=2E The fact that h=
as not been explicitly defined before now =E2=80=94 due to the fact it wasn=
't relevant before this RFC =E2=80=94 does not automatically require that i=
t not be a formal part of the function signature, that is just the implicit=
 status quo=2E This is likely something this RFC or a precursor RFC should =
ask voters to vote on explicitly, and then it would be decided=2E


Well, that would get an immediate "no" from me=2E I see absolutely no reas=
on to restrict a function's choice of default beyond being valid for the de=
clared type=2E


Rowan Tommins
[IMSoP]