> Am 16.03.2016 um 18:27 schrieb Chris Riley <t.carn...@gmail.com>: > On 16 March 2016 at 17:17, Bob Weinand <bobw...@hotmail.com > <mailto:bobw...@hotmail.com>> wrote: > > Am 16.03.2016 um 17:36 schrieb Phil Sturgeon <pjsturg...@gmail.com > > <mailto:pjsturg...@gmail.com>>: > > 2. This whole temporary nullability situation, where unset properties > > will error on attempted usage if not set. Should they instead error > > after the constructor has been called if they are still not holding a > > value? > > Erroring when using the unset property is the way to go. > > The example from the RFC is showing exactly why... > > class Foo { > public int $foo; > } > $foo = new Foo(); > echo $foo->foo; // Patch currently errors here > > With one property, not so much an issue, we could force a constructor. > But with 20 properties, definitely an issue. > > If we'd error after constructor call, there are also other complications… > > class Foo { > public int $bar; > function __construct() { > global $foo; > $foo = $this; > } > } > try { > new Foo; > } catch (Error $e) {} > var_dump($foo->bar); // not set, but instance is referenced > > Sure, we could find ways to circumvent that and change the class to totally > non-functional and making every usage of it throw an Error, but it isn't > quite elegant. > > I'm not 100% convinced that we need this now we have full type hint support > for parameters and return types; but it does have potential to remove boiler > plate for public properties. For point 2 nullable properties, how about some > syntax which allows for a property to be null, or for it to be a specific > type. I'd suggest a null assignment to fall in line with parameter type hints > eg: > > class Foo { > protected int $bar = null; //can be null > private stdClass $baz; //can't be null > }
The point is basically, the value should never be accessed and actually return null. If it is accessed, it always should return the type I provided. Having it potentially return null would completely miss the point (and also confuse static analysis which would assume the value could be null, when in reality it never should be). Concrete example: https://github.com/amphp/aerys/blob/master/lib/InternalRequest.php <https://github.com/amphp/aerys/blob/master/lib/Client.php> That's a bunch of public properties (value object). The values are all initialized when the object is created — if a property is accessed and was forgotten to be initialized, it should error. That's helpful for detecting bugs. You definitely don't want to define these values, which are supposed to be set upon initialization, to be _possibly_ null. Because they actually are never null from their first read access on. E.g. InternalRequest->responseWriter is *always* a Generator object when accessed. The value is *never* potentially null (and thus would theoretically have to be checked for being null or not). Having to force null here, would be a big mistake. Semantically and for static analysis. Bob
