Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114389
User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416
Mime-Version: 1.0
Message-ID: <a13b73ae-c7e4-44f0-bc4b-5cdd3abb1ed5@www.fastmail.com>
In-Reply-To: <47e8f7c7-6ae6-3744-b590-c3f39b144c46@gmail.com>
References: 
 <CAF+90c-HY-0fx+pTmntRJZKcQcZFfk3uJwrZ6FAMAx5_Wj+JHw@mail.gmail.com>
 <CAAwdEzApyQd52RpJ-gW+pNtBA=jA1bn74c-K1djcztRRgaYAag@mail.gmail.com>
 <CAF+90c8YMpGNLKehfFW6gWJx0mGUVqL0Rx+U262gGRP6cTXBgw@mail.gmail.com>
 <CAAwdEzDwD5sc6AQxLSnj0Dx=4ZsP1h0K83TS+jyN1x5_X7NAAg@mail.gmail.com>
 <CAF+90c9_=GkKbErf-z464_zqAHCDERbdLjd_uyoNvC9PERxoxQ@mail.gmail.com>
 <CAF+90c_WVD3jDtrtVbAuPGPWf9v6Hz4h2i=nrgHi+4Axx4157Q@mail.gmail.com>
 <CAF+90c9WXzqVnJ-U6Sj=xP39rEn03FDksdLG85T=e_+ZhdCXTA@mail.gmail.com>
 <CAF+90c_YSo_W6twktGg0nZ16Tr+qx_xsEucsOSdh6=uS8kTSAQ@mail.gmail.com>
 <3f3cb374-23d8-9d26-4ea2-fe891538a7b6@gmail.com>
 <47e8f7c7-6ae6-3744-b590-c3f39b144c46@gmail.com>
Date: Tue, 11 May 2021 09:41:41 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] New in initializers
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, May 11, 2021, at 8:57 AM, Rowan Tommins wrote:
> On 11/05/2021 14:12, Dik Takken wrote:
> > So the use of "new" in initializers would require extending this bas=
e
> > class and call the parent constructor. Maybe forgetting to do so cou=
ld
> > throw, preventing initializers from silently not working.
>=20
>=20
> If we managed to get that working, I wonder if we could also include a=
=20
> check for uninitialized typed properties, a bit like Swift's "two-phas=
e=20
> initializers". In short, make this throw an error:
>=20
> class Foo extends \PHP\Base {
>  =C2=A0=C2=A0=C2=A0 private Logger $logger;
>=20
>  =C2=A0=C2=A0=C2=A0 public function __construct() {
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 parent::construct(); // "E=
rror: Property $logger has no default=20
> and was not initialized before calling Base constructor"
>  =C2=A0=C2=A0=C2=A0 }
> }
>=20
> This would catch bugs closer to their source, where currently there is=
=20
> no error until $logger is accessed.
>=20
>=20
> However, the "if" at the beginning of this message is quite a big one:=
=20
> it's not obvious where to assert any of this, because the constructor =
is=20
> just called as a normal method *after* the engine considers the object=
=20
> to be "created".

In practice, I almost always see the parent constructor called first, th=
en the child constructor does its own thing.  Having the language requir=
e you to do it backwards in order to use a new feature would be... well,=
 not technically a BC break per se, but certainly invalidating what is c=
urrently standard practice.

If I'm following correctly, the concern is cases like this:

class Point {
  private Logger $logger =3D new FancyLogger();
  public function __construct(public int $x, public int $y) {
    $this->logger->log("Point made.");
  }
}

class FancyLogger {
    public function __construct() {
      $this->db =3D new DatabaseConnection();
      $this->db->write('Logger start.');
    }
}

$p1 =3D new Point(); // This writes "Logger start" then "Point made."

$p2 =3D unserialize(serialize($p1)); // This writes just "Logger start."=


Am I understanding that right?  If so, I'm... unclear why that is any mo=
re of an issue than doing it the manual way now.

--Larry Garfield