Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125352
Date: Thu, 29 Aug 2024 18:04:12 -0400
To: Bilge <bilge@scriptfusion.com>
Cc: "=?utf-8?Q?internals=40lists.php.net?=" <internals@lists.php.net>
Message-ID: <8BFBC80D-589E-4297-A019-031B6D121F3A@getmailspring.com>
In-Reply-To: <fe37b0bc-af11-4209-94bd-c60db59671ff@scriptfusion.com>
References: <fe37b0bc-af11-4209-94bd-c60db59671ff@scriptfusion.com>
Subject: Re: [PHP-DEV] Re: [RFC] Default expression
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66d0f05c_643c9869_129d4"
From: john@coggeshall.org (John Coggeshall)

--66d0f05c_643c9869_129d4
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

One thought re-reading the RFC.

abstract class Theme {
public function bar();
}

class CuteTheme extends Theme {
public function foo();
}

class Config {
public function __construct(Theme $theme = new CuteTheme()) {}
}

$a = new Config(default->foo());
In the proposed (updated) RFC would this be proposed to work? If so this should be added to the discussion section as something I think is equally as problematic as union types. I don't think saying "Union and Mixed" is broad enough. In this case it would actually have to only allow Theme (whatever that was) and prevent you from calling foo() because that isn't a member of Theme . Otherwise it's the same problem as union types in a different color.
Coogle
On Aug 29 2024, at 5:52 pm, Bilge <bilge@scriptfusion.com> wrote:
> Hi gang,
>
> On 24/08/2024 17:49, Bilge wrote:
> >
> > New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
> > think some of you might enjoy this one. Hit me with any feedback.
> >
> Now the dust has settled, I've updated the RFC to version 1.1. The
> premise of the RFC is unchanged, but the proposal has been expanded and
> a discussion section added to summarise the ~100 message thread to
> capture the major concerns raised in a condensed format. I hope I've
> done a good job of fairly and accurately representing your concerns, but
> if not please correct me.
>
> Furthermore, a secondary vote has been added. The secondary vote will be
> open to all (whether in favour or against the proposal) to capture
> alternative implementations you might also be in favour of. If the
> primary vote passes, the secondary vote won't matter, but otherwise it
> may help guide our sails in future.
>
> Kind regards,
> Bilge
>


--66d0f05c_643c9869_129d4
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>One thought re-reading the R=46C.</div><br><div>abstract class Theme=
 =7B</div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public fu=
nction bar();</div><div>=7D</div><br><div>class CuteTheme extends Theme =7B=
</div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public function foo();</d=
iv><div>=7D</div><br><div>class Config =7B</div><div>&nbsp;&nbsp;&nbsp; p=
ublic function =5F=5Fconstruct(Theme =24theme =3D new CuteTheme()) =7B=7D=
</div><div>=7D</div><br><div>=24a =3D new Config(default-&gt;foo());</div=
><br><div>In the proposed (updated) R=46C would this be proposed to work=3F=
 If so this should be added to the discussion section as something I thin=
k is equally as problematic as union types. I don't think saying =22Union=
 and Mixed=22 is broad enough. In this case it would actually have to onl=
y allow <code>Theme</code>&nbsp; (whatever that was) and prevent you from=
 calling <code>foo()</code>&nbsp; because that isn't a member of <code>Th=
eme</code>&nbsp;. Otherwise it's the same problem as union types in a dif=
ferent color.</div><br><div>Coogle</div><br><div class=3D=22gmail=5Fquote=
=5Fattribution=22>On Aug 29 2024, at 5:52 pm, Bilge &lt;bilge=40scriptfus=
ion.com&gt; wrote:</div><blockquote><div><div>Hi gang,</div><br><div>On 2=
4/08/2024 17:49, Bilge wrote:</div><div>&gt;</div><div>&gt; New R=46C jus=
t dropped: https://wiki.php.net/rfc/default=5Fexpression. I</div><div>&gt=
; think some of you might enjoy this one. Hit me with any feedback.</div>=
<div>&gt;</div><div>Now the dust has settled, I've updated the R=46C to v=
ersion 1.1. The</div><div>premise of the R=46C is unchanged, but the prop=
osal has been expanded and</div><div>a discussion section added to summar=
ise the =7E100 message thread to</div><div>capture the major concerns rai=
sed in a condensed format. I hope I've</div><div>done a good job of fairl=
y and accurately representing your concerns, but</div><div>if not please =
correct me.</div><br><div>=46urthermore, a secondary vote has been added.=
 The secondary vote will be</div><div>open to all (whether in favour or a=
gainst the proposal) to capture</div><div>alternative implementations you=
 might also be in favour of. If the</div><div>primary vote passes, the se=
condary vote won't matter, but otherwise it</div><div>may help guide our =
sails in future.</div><br><div>Kind regards,</div><div>Bilge</div></div><=
/blockquote>
--66d0f05c_643c9869_129d4--