Morning Dmitry, > I made this check(s) to be invariant. You may like to do this differently...
I think this is what everyone expects, isn't it ? I did omit to mention that part ... > RFC doesn't define how uninitialized nullable typed properties should behave. It does: > *Nullable typed properties will not raise an exception when accessed before initialization.* It's the only bold text in the document :) It seems correct to me; We raise uninitialized exceptions to prohibit the return of null to user land, for nullable properties we don't need to do that. It does mean that ?int $foo; has an implicit default value of null, but I can't see anything wrong with that, for a nullable property. I'm open to being persuaded that is wrong. I will review comments and current patch this morning ... Cheers Joe On Wed, May 25, 2016 at 8:06 AM, Dmitry Stogov <dmi...@zend.com> wrote: > > > On 05/25/2016 09:06 AM, Joe Watkins wrote: > > Morning Dmitry, > > There's no section for nullables, but there is mention of them, > specifically in relation to your query: > > > While parameters allow null to be accepted as the default value, null > is only a valid value for nullable properties. > > Is there something wrong with that rule ? > > > It's OK. This just should be defined and it's defined in RFC (I missed) > > > Having explicit nullability means the declaration tells you all you > need to know, all the time. > > Being able to set null any typed property means you can never be sure > of the type; You can't tell by looking at the declaration what type the > variable will be because anything is allowed to set it null. > > We waited for explicit nullability to avoid this. > > You'll have to have a really good reason for me to change that rule :) > > > Inheritance rules for typed nullable properties are also missed. > > That's true, but shouldn't they use the same rules as nullable > parameters, will discussion change how they should work ? > > I made this check(s) to be invariant. You may like to do this > differently... > It's better to define this in RFC, check implementation and add tests. > > > > but still have unsolved problems. > > If you have discussed these somewhere, can you send/show the transcript > ? (I missed all comms after yesterday morning, due to illness). > > > We are working with Bob, trying to improve the patch. I added new tests > fixing the problems, and also added few comments o github. > > > If it emerges that the RFC needs to be modified heavily, then I'm happy > to stop the voting. > > > RFC doesn't define how uninitialized nullable typed properties should > behave. > > class C { > public $a; > public int $b; > public ?int $c; > } > $obj = new C; > var_dump($obj->a); // NULL > var_dump($obj->b); // throw Error("") > var_dump($obj->c); // first or second??? (currently throw Error("")). > $obj->$a = null; > $obj->$b = null; // throw Error("") > $obj->$c = null; > var_dump($obj->a); // NULL > var_dump($obj->b); // throw Error("") > var_dump($obj->c); // NULL > unset($obj->$a); > unset($obj->$b); > unset($obj->$c); > var_dump($obj->a); // notice + NULL > var_dump($obj->b); // throw Error("") > var_dump($obj->c); // first or second??? (currently throw Error("")). > > This should be defined. > > > > But, so far, we haven't actually deviated from the RFC, only changed > implementation details that are not part of the design of the feature. > > > I'm not so sure. > Anyway, I hope you are better and we will able to speak today or tomorrow. > > Thanks. Dmitry. > > > > Sorry if it seems like I'm missing information, I don't know what you > and Bob found out yet ... > > I super appreciate you guys working on it, obviously. Thanks for that :) > > Cheers > Joe > > On Tue, May 24, 2016 at 8:04 PM, Dmitry Stogov <dmi...@zend.com> wrote: > >> Hi Joe, >> >> I've add implementation for nullable typed properties (as they fit into >> the patch design), but RFC missed any description of nullable properties. >> See tests Zend/tests/type_declarations/typed_properties_047.phpt, >> Zend/tests/type_declarations/typed_properties_048.phpt, >> Zend/tests/type_declarations/typed_properties_049.phpt >> >> I'm not sure, if this is what the voters expect. At least I don't like >> the facts that "?int $foo;" declares uninitialized property; "?int $foo = >> NULL" may be unset() and became uninitialized; and it's an open question if >> "int $foo = NULL;" should be supported as nullable. Inheritance rules for >> typed nullable properties are also missed. >> >> Personally, I think the RFC was moved into voting state too early >> (without good enough implementation, and with missing topics). >> The current implementation is better (performance penalty reduced to >> ~2%), but still have unsolved problems. >> >> May be it's better to cancel voting, solve problems, finish the >> implementation and add missing questions into RFC... >> I'm going to help with implementation in any case, but we should agree on >> what we are doing. >> >> Thanks. Dmitry. >> >> ________________________________________ >> From: Joe Watkins <pthre...@pthreads.org> >> Sent: Friday, May 20, 2016 9:05:34 AM >> To: PHP internals; Phil Sturgeon >> Subject: [PHP-DEV] [RFC][Vote] Typed Properties >> >> Morning internals, >> >> Since we have our answer on nullable types, typed properties can now >> go >> to vote. >> >> https://wiki.php.net/rfc/typed-properties#vote >> >> Note that, support for nullability as RFC'd will be merged when the >> implementation for nullable_types is merged into master. >> >> Please participate. >> >> Cheers >> Joe >> > > >