Morning Dmitry, > I suppose it should emit notice and return NULL.
Yes, as untyped properties do (they would also invoke magic for unset, but defined property). > I'll change this as well (in an hour). Thanks ... Nullable property support was missing from the implementation, completely, because it wasn't merged at the time, but I did mention it would be added. It seems like we are changing details that should have been mentioned, we're not in some cases, just clarifying them ... but I admit it's clarification that should have been included in the RFC in some cases. I would like to know what others think about halting the vote, and reopening in a few days when we have finalized the implementation, and possibly put some finishing touches on the RFC. If a few people want that to happen, happy to do it ... personally, I don't think we've deviated from the RFC. Cheers Joe On Wed, May 25, 2016 at 9:36 AM, Dmitry Stogov <dmi...@zend.com> wrote: > > > On 05/25/2016 11:30 AM, Joe Watkins wrote: > > 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. > > > OK. This is the same that I like. I'll change implementation accordingly. > But what should unset() do? > Currently it makes property uninitialized and then it can't accessed. > I suppose it should emit notice and return NULL. > I'll change this as well (in an hour). > > Thanks. Dmitry. > > > 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> >> 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>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 >>> >> >> >> > >