Re: [RFC][Vote] Typed Properties

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

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc