[RFC][Vote] Typed Properties

> It'd be a BC break if we changed untyped properties' behaviour, yeah. We

> wouldn't be inventing a new null, though, we'd be leaving the property > undefined until it's initialised, which we already have support for > (properties, and indeed all variables can be unset()).

>>> A simple example might be a Lisp-style linked list cell: >>> >>> class LinkedList >>> { >>> public int $head; >>> public ?LinkedList $tail; >>> } >>> >>> In a properly initialised LinkedList, the $head is some value, and the >>> $tail is either another linked list (the remainder of the list), or null >>> (we're at the end of the list). >> >> This is a very weird list, as it can't be empty. > > The empty list is represented by null in this arrangement.

> Am 25.05.2016 um 17:57 schrieb James Gilliland <neclimdul@gmail.com>: > > This is a cool idea and continuation of the typing systems so I've been > sort of skimming this thread as its been discussed and this example and the > associated errors caught my attention. > >> class C { >> public $a; >> public int $b; >> public ?int $c; >> } >> $obj = new C; >> > > Excuse me if this has been addressed but to clarify, using that snippet, > would this also throw an error? > > var_dump($obj); > > If so, I see a lot of cursing in my future if this goes in. Like "what's > the bad data on this object that's getting in here? aww #$%^ that > deprecated property wasn't set so the whole thing blew up!" sort of > cursing. :(

> Am 25.05.2016 um 18:21 schrieb Niklas Keller <me@kelunik.com>: > >> >> Hi Niklas, >> >> Niklas Keller wrote: >> >>> >>> 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. >>> >>> 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. >>> >> >> 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. >> > > Null shouldn't have any meaning apart from "not set". It should never be a > meaningful value. > > >> 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. >> >> Consider that we did something like this for parameters. Not providing an >> untyped parameter gives an E_WARNING: >> >> $ 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 >> >> But not providing a typed parameter gives a TypeError: >> >> $ 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 >> >> So there's a precedent for applying stricter rules when type declarations >> are used. >> >> Thanks! >> >> >> -- >> Andrea Faulds >> https://ajf.me/

> 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.

> We already have the differentiation between IS_NULL and IS_UNDEF, why > not expose the latter to userland?

> We already have the differentiation between IS_NULL and IS_UNDEF, why > not expose the latter to userland?