Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125278
Date: Mon, 26 Aug 2024 13:35:02 -0400
To: Mike Schinkel <mike@newclarity.net>
Cc: "=?utf-8?Q?internals=40lists.php.net?=" <internals@lists.php.net>, 
 =?utf-8?Q?Rowan_Tommins_=5BIMSoP=5D?= <imsop.php@rwec.co.uk>, Andreas
 Leathley <a.leathley@gmx.net>, Andreas Heigl <andreas@heigl.org>
Message-ID: <172E530A-7D97-4E00-84AB-81057C837461@getmailspring.com>
In-Reply-To: <07E4ABD5-B9CE-47FA-BD9E-E42A82CFC737@newclarity.net>
References: <07E4ABD5-B9CE-47FA-BD9E-E42A82CFC737@newclarity.net>
Subject: Re: [PHP-DEV] [RFC] Default expression
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66ccbcc6_6b8b4567_12a23"
From: john@coggeshall.org (John Coggeshall)

--66ccbcc6_6b8b4567_12a23
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


> From the example you gave it appears that we can have a concrete problem when:
> 1. There is a parameter with a default value,
> 2. That parameter is type-hinted,
> 3. The hinted type is declared as a union type,
> 4. An earlier version of the library initialized the default with a value having one of the union types,
> 5. End-user developers used the library and then use `default` as an expression of that type, and finally
> 6. The library developer changed the initialization of the `default` to a different type from the union.
>
> Did I correctly identify the problematic use-case?

Not really. #2 and #3 are irrelevant mixed is actually much more problematic, I wanted to provide an example that was strongly typed intentionally to show the problem even when types were explicit. The relevant portion is #1, #5 and #6.
> Ok, so for argument sake, what if they revise the RFC to only allow `default` to be used in an expression when the parameter is not type-hinted with a union? Would that address your concern? Or are there other use-cases that are problematic that do not hinge on the parameter being type-hinted as a union type?
It wouldn't be enough, offhand it'd also have to be forbidden for mixed (at which point I think the utility isn't there anymore).


--66ccbcc6_6b8b4567_12a23
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><blockquote><div><div>=46rom the example you gave it appears that we =
can have a concrete problem when:</div><br><div>1. There is a parameter w=
ith a default value,</div><div>2. That parameter is type-hinted,</div><di=
v>3. The hinted type is declared as a union type,</div><div>4. An earlier=
 version of the library initialized the default with a value having one o=
f the union types,</div><div>5. End-user developers used the library and =
then use =60default=60 as an expression of that type, and finally</div><d=
iv>6. The library developer changed the initialization of the =60default=60=
 to a different type from the union.</div><br><div>Did I correctly identi=
fy the problematic use-case=3F</div></div></blockquote><div><br><div>Not =
really. =232 and =233 are irrelevant <code>mixed</code>&nbsp; is actually=
 much more problematic, I wanted to provide an example that was strongly =
typed intentionally to show the problem even when types were explicit. Th=
e relevant portion is =231,&nbsp; =235 and =236.</div><br><blockquote>Ok,=
 so for argument sake, what if they revise the R=46C to only allow =60def=
ault=60 to be used in an expression when the parameter is not type-hinted=
 with a union=3F Would that address your concern=3F Or are there other us=
e-cases that are problematic that do not hinge on the parameter being typ=
e-hinted as a union type=3F</blockquote><br><div>It wouldn't be enough, o=
ffhand it'd also have to be forbidden for <code>mixed</code>&nbsp; (at wh=
ich point I think the utility isn't there anymore).</div><br><br></div>
--66ccbcc6_6b8b4567_12a23--