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
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
