Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93535 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 51289 invoked from network); 25 May 2016 21:35:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 May 2016 21:35:51 -0000 Authentication-Results: pb1.pair.com smtp.mail=mails@thomasbley.de; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=mails@thomasbley.de; sender-id=unknown Received-SPF: error (pb1.pair.com: domain thomasbley.de from 85.13.128.151 cause and error) X-PHP-List-Original-Sender: mails@thomasbley.de X-Host-Fingerprint: 85.13.128.151 dd1730.kasserver.com Received: from [85.13.128.151] ([85.13.128.151:41590] helo=dd1730.kasserver.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F8/DD-14311-5BA16475 for ; Wed, 25 May 2016 17:35:50 -0400 Received: from dd1730.kasserver.com (dd0800.kasserver.com [85.13.143.204]) by dd1730.kasserver.com (Postfix) with ESMTPSA id D7EE41A801B3; Wed, 25 May 2016 23:35:46 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SenderIP: 95.91.244.236 User-Agent: ALL-INKL Webmail 2.11 In-Reply-To: <1b12b09f-f190-dca0-51d9-468e9c571268@fleshgrinder.com> References: <7B.12.14311.F79C5475@pb1.pair.com><1b12b09f-f190-dca0-51d9-468e9c571268@fleshgrinder.com> To: ajf@ajf.me, internals@lists.php.net Cc: ocramius@gmail.com, bensor987@neuf.fr, me@kelunik.com, smalyshev@gmail.com Message-ID: <20160525213546.D7EE41A801B3@dd1730.kasserver.com> Date: Wed, 25 May 2016 23:35:46 +0200 (CEST) Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties From: mails@thomasbley.de ("Thomas Bley") Following "Type safety is the goal of this RFC, not validating objects.", it would be better to do implicit casting for uninitialized properties (whenever implicit casting is possible) or use null for nullable types: class A { public int $x; public ?int $y = null; public int $z = 42; public ?int $u; public ?datetime $v; public datetime $w; } $a = new A; var_dump($a->x); // 0 + notice var_dump($a->y); // null var_dump($a->z); // 42 unset($a->z); var_dump($a->z); // 0 + notice var_dump($a->u); // null + notice var_dump($a->v); // null + notice var_dump($a->w); // Fatal error, uninitialized... Regards Thomas Fleshgrinder wrote on 25.05.2016 23:03: > On 5/25/2016 5:49 PM, Andrea Faulds wrote: >> PHP's existing untyped properties are implicitly initialised to null, >> and so yes, we would essentially only be copying our existing behaviour. >> >> However, I think it is worth asking whether our existing behaviour is >> useful before we preserve it here. From my perspective, it is unhelpful >> that PHP does not warn you about using properties you haven't >> initialised, and this applies to both typed and untyped properties. In >> some cases (like in my linked list example in a previous email), null >> might be a meaningful value and worth distinguishing from a property not >> having being initialised yet. >> >> We can't change the behaviour of our existing untyped properties (or at >> least, that's beyond the scope of this RFC), but we could choose the >> behaviour we find more useful for our typed properties. >> > > We already have the differentiation between IS_NULL and IS_UNDEF, why > not expose the latter to userland? I mean, JavaScript has it too and > people are able to understand it. > > class A { > > public int $x; > > public ?int $y = null; > > public int $z = 42; > > } > > $a = new A; > var_dump($a->x); // undefined > var_dump($a->y); // null > var_dump($a->z); // 42 > unset($a->z); > var_dump($a->z); // undefined + error > > At least to me this makes sense and there would be no problem with > unset() anymore. Although I truly question the usefulness of its > functionality. Can anyone come up with a real world use case for unset()? > > Or maybe not use /undefined/ but /unset/ as a term because it is already > baked in? (Well the constant IS_UNDEF should be renamed to IS_UNSET to > stay consistent in all layers.) > > class A { > > public int $x; > > public ?int $y = null; > > public int $z = 42; > > } > > $a = new A; > var_dump($a->x); // unset > var_dump($a->y); // null > var_dump($a->z); // 42 > > // NOT SURE IF THIS SHOULD BE POSSIBLE!!!! > $a->z = (unset) $a->z; // was null (PHP<7.1) would become unset > var_dump($a->z); // unset + error > > $a->z = unset; > var_dump($a->z); // unset + error > > unset($a->z); > var_dump($a->z); // unset + error > > Of course this would also requires the introduction of an unset (and > UNSET) constant in userland. > > class A { > > private $x; > > public function getX() { > if ($x === unset) { > $this->x = 42; > } > return $this->x; > } > > } > > I love the difference to null, this makes the code much more expressive. > > There would be the following rules: > - Access always results in error. > - Usage as argument results in error. > - Usage as return results in error (could be void but BC). > - ... more errors ... > - Comparison is possible! > - The following existing operations would need to be changed to make use > of unset instead of null (possible BC): > - unset() > - (unset) cast > - The following new operations would need to be introduced: > - is_unset() > - The following existing operations would need to be extended: > - gettype() > - settype() > > -- > Richard "Fleshgrinder" Fussenegger > >