Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:93515 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1590 invoked from network); 25 May 2016 16:38:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 May 2016 16:38:40 -0000 Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.140 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.111.140 blu004-omc4s1.hotmail.com Received: from [65.55.111.140] ([65.55.111.140:62176] helo=BLU004-OMC4S1.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F9/44-14311-E05D5475 for ; Wed, 25 May 2016 12:38:39 -0400 Received: from BLU436-SMTP246 ([65.55.111.137]) by BLU004-OMC4S1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 25 May 2016 09:38:36 -0700 X-TMN: [z+hKYb4HqnQSzKYYIhk898c38GBoRGpB] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) In-Reply-To: Date: Wed, 25 May 2016 18:38:31 +0200 CC: Andrea Faulds , PHP Internals Content-Transfer-Encoding: quoted-printable References: <7B.12.14311.F79C5475@pb1.pair.com> To: Niklas Keller X-Mailer: Apple Mail (2.3112) X-OriginalArrivalTime: 25 May 2016 16:38:33.0866 (UTC) FILETIME=[E0D86EA0:01D1B6A3] Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties From: bobwei9@hotmail.com (Bob Weinand) Hey Niklas, > Am 25.05.2016 um 18:21 schrieb Niklas Keller : >=20 >>=20 >> Hi Niklas, >>=20 >> Niklas Keller wrote: >>=20 >>>=20 >>> I disagree here. Properties are always null by default. The current = patch >>> disallows >>> access to uninitialized variables only if they're not nullable, = since null >>> isn't a valid value then. >>>=20 >>> I don't think having to explicitly set them to null is the think we = want. >>> And it's not what I'd expect given the current system. >>>=20 >>=20 >> PHP's existing untyped properties are implicitly initialised to null, = and >> so yes, we would essentially only be copying our existing behaviour. >>=20 >> However, I think it is worth asking whether our existing behaviour is >> useful before we preserve it here. =46rom 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. >>=20 >=20 > Null shouldn't have any meaning apart from "not set". It should never = be a > meaningful value. >=20 >=20 >> 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. >>=20 >> Consider that we did something like this for parameters. Not = providing an >> untyped parameter gives an E_WARNING: >>=20 >> $ php -r 'function foo($a) {} foo();' >> PHP Warning: Missing argument 1 for foo(), called in Command line = code on >> line 1 and defined in Command line code on line 1 >>=20 >> But not providing a typed parameter gives a TypeError: >>=20 >> $ php -r 'function foo(int $a) {} foo();' >> PHP Fatal error: Uncaught TypeError: Argument 1 passed to foo() must = be >> of the type integer, none given, called in Command line code on line = 1 and >> defined in Command line code:1 >> Stack trace: >> #0 Command line code(1): foo() >> #1 {main} >> thrown in Command line code on line 1 >>=20 >> So there's a precedent for applying stricter rules when type = declarations >> are used. >>=20 >> Thanks! >>=20 >>=20 >> -- >> Andrea Faulds >> https://ajf.me/ There is a difference between not set and no meaningful value. The former is literally unset(), the latter is null. The only semantics = PHP exposes here is that not set can be upgraded to "no meaningful" = value in form of null with a notice. The difference thus is quite minor, but semantically important. Hence to *set* the value, we need to explicitly set null. If we don't do it this way, we won't have a way to explicitly *set* = nullable properties to a value (null in this case). (without explicit = unset in ctor). Bob=