# [RFC][Vote] Typed Properties - Thread: https://externals.io/message/93407 - Original archive: https://news-web.php.net/php.internals/93407 - Started by Joe Watkins on 2016-05-20T06:05:34+00:00 - Messages: 81 - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/93407.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #93407 — Joe Watkins — 2016-05-20T06:05:34+00:00 URL: https://externals.io/message/93407#93407 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 --- ## #93410 — Larry Garfield — 2016-05-20T08:08:29+00:00 URL: https://externals.io/message/93407#93410 · In reply to: #93407 > 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 I don't get a vote, but I will say "endorse!" --Larry Garfield --- ## #93412 — Lester Caine — 2016-05-20T09:25:59+00:00 URL: https://externals.io/message/93407#93412 · In reply to: #93407 > 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. I have just realised exactly why I have a problem with most of this ... Domain! Used as an 'OtherThing' This is ALSO attributes, since an SQL domain defines all of the attributes that I need to handle in relation to variables. 'int' on it's own does very little since one still needs to add all the other checks, but adding 'types' as a properly formatted domain solves all the problems I'm looking at ... and leaves plenty of room for others to abuse the in their own way? http://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-ddl-domn.html Note such elements as [] to allow for arrays of a datatype although that still leaves the handling of mix arrays. Some of the conditions may seem irreverent, but if the domain is a set of keys for an array that logic then makes sense? I can even see the addition of a 'read only' flag to solve that problem while still constraining the initial setting of a domain. But this is simply user land code and does not need a small subset of elements of it added to the code base? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #93422 — guilhermeblanco@gmail.com — 2016-05-20T15:47:12+00:00 URL: https://externals.io/message/93407#93422 · In reply to: #93412 Joe, I fixed a minor typo in the RFC, hope you didn't mind. =) > > > […] > go > > […] > > I have just realised exactly why I have a problem with most of this ... > Domain! Used as an 'OtherThing' > > This is ALSO attributes, since an SQL domain defines all of the > attributes that I need to handle in relation to variables. 'int' on it's > own does very little since one still needs to add all the other checks, > but adding 'types' as a properly formatted domain solves all the > problems I'm looking at ... and leaves plenty of room for others to > abuse the in their own way? > > > http://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-ddl-domn.html > > Note such elements as [] to allow for arrays of a datatype > although that still leaves the handling of mix arrays. > > Some of the conditions may seem irreverent, but if the domain is a set > of keys for an array that logic then makes sense? > > I can even see the addition of a 'read only' flag to solve that problem > while still constraining the initial setting of a domain. > > But this is simply user land code and does not need a small subset of > elements of it added to the code base? > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk > > -- > > > > -- Guilherme Blanco Lead Architect at E-Block --- ## #93423 — Tom Worster — 2016-05-20T17:59:22+00:00 URL: https://externals.io/message/93407#93423 · In reply to: #93407 > 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. I lack suffrage but I have a question about coercion and strictness. When I assign a value to a property declared with scalar type, is it the strictness of the file containing the assignment that controls if coercion happens or not? And is the strictness of the file containing the declaration irrelevant? I guess yes on both to be consistent with coercion on function invocation but I couldn't find this mentioned in the RFC. Tom --- ## #93424 — Joe Watkins — 2016-05-21T06:10:42+00:00 URL: https://externals.io/message/93407#93424 · In reply to: #93423 Morning Tom, > I guess yes on both to be consistent with coercion on function invocation but I couldn't find this mentioned in the RFC. Correct. I only made brief mention that the rules for coercion and strictness are reused. Cheers Joe > > > > […] > > I lack suffrage but I have a question about coercion and strictness. > > When I assign a value to a property declared with scalar type, is it the > strictness of the file containing the assignment that controls if coercion > happens or not? And is the strictness of the file containing the > declaration irrelevant? > > I guess yes on both to be consistent with coercion on function invocation > but I couldn't find this mentioned in the RFC. > > Tom --- ## #93433 — Dmitry Stogov — 2016-05-23T08:04:03+00:00 URL: https://externals.io/message/93407#93433 · In reply to: #93407 The patch "corrupts" opcache shared memory. PHP crashes with opcache.protect_memory=1. $ USE_ZEND_ALLOC=0 valgrind sapi/cli/php -d opcache.protect_memory=1 ../Zend/tests/type_declarations/typed_properties_027.php ==900== Memcheck, a memory error detector ==900== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==900== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==900== Command: sapi/cli/php ../Zend/tests/type_declarations/typed_properties_027.php ==900== ==900== ==900== Process terminating with default action of signal 11 (SIGSEGV) ==900== Bad permissions for mapped region at address 0xF00FFBC8 ==900== at 0x86391FE: zend_verify_weak_scalar_type_hint (zend_execute.c:725) ==900== by 0x8639833: zend_verify_scalar_property_type (zend_execute.c:869) ==900== by 0x8639C2B: zend_verify_property_type (zend_execute.c:938) ==900== by 0x862E46D: zend_std_write_property (zend_object_handlers.c:753) ==900== by 0x8685102: ZEND_ASSIGN_OBJ_SPEC_CV_CONST_OP_DATA_CONST_HANDLER (zend_vm_execute.h:42160) ==900== by 0x863F91D: execute_ex (zend_vm_execute.h:426) ==900== by 0x863F9D2: zend_execute (zend_vm_execute.h:471) ==900== by 0x85F38B4: zend_execute_scripts (zend.c:1427) ==900== by 0x85832B7: php_execute_script (main.c:2492) ==900== by 0x86AE2D8: do_cli (php_cli.c:982) ==900== by 0x86AEF42: main (php_cli.c:1352) ==900== --- ## #93436 — Dmitry Stogov — 2016-05-23T08:30:09+00:00 URL: https://externals.io/message/93407#93436 · In reply to: #93407 Hi Joe, The performance effect of this implementation is terrible. Assignment to typed property is 2.3 times slower. Assignment to untyped property in a class with typed properties is 1.8 times slower. See the benchmark https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb800 Thanks. Dmitry. ________________________________________ From: Joe Watkins 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 --- ## #93437 — Dmitry Stogov — 2016-05-23T09:02:16+00:00 URL: https://externals.io/message/93407#93437 I appreciate the work done by Joe, but I vote "no", because the implementation is not good enough yet - it's incompatible with opcache (may be it's not a big problem to fix this) - typed properties assignment is going to be 2-3 times slower ($obj->x += 2; is 3 times slower) - the patch makes slight negative effect even for untyped properties - the proposed behavior for uninitialized typed properties assumes that they have to be checked on each "read". This checks will have to be performed even in native JITed code. I don't see a reason for typing if we have to perform check on each read anyway. Thanks. Dmitry. ________________________________________ From: Dmitry Stogov Sent: Monday, May 23, 2016 11:30:09 AM To: Joe Watkins; PHP internals; Phil Sturgeon Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties Hi Joe, The performance effect of this implementation is terrible. Assignment to typed property is 2.3 times slower. Assignment to untyped property in a class with typed properties is 1.8 times slower. See the benchmark https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb800 Thanks. Dmitry. ________________________________________ From: Joe Watkins 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 --- ## #93439 — Ivan Enderlin — 2016-05-23T09:06:40+00:00 URL: https://externals.io/message/93407#93439 · In reply to: #93437 I vote no for the same performance reason, but the whole Hoa's community is agree with the RFC. Thanks for the hard work! > I appreciate the work done by Joe, but I vote "no", because the implementation is not good enough yet > > - it's incompatible with opcache (may be it's not a big problem to fix this) > - typed properties assignment is going to be 2-3 times slower ($obj->x += 2; is 3 times slower) > - the patch makes slight negative effect even for untyped properties > > - the proposed behavior for uninitialized typed properties assumes that they have to be checked on each "read". This checks will have to be performed even in native JITed code. I don't see a reason for typing if we have to perform check on each read anyway. > > Thanks. Dmitry. > ________________________________________ > From: Dmitry Stogov > Sent: Monday, May 23, 2016 11:30:09 AM > To: Joe Watkins; PHP internals; Phil Sturgeon > Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties > > Hi Joe, > > The performance effect of this implementation is terrible. > > Assignment to typed property is 2.3 times slower. > Assignment to untyped property in a class with typed properties is 1.8 times slower. > > See the benchmark > https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb800 > > Thanks. Dmitry. > ________________________________________ > From: Joe Watkins > 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 --- ## #93438 — Stanislav Malyshev — 2016-05-23T09:09:13+00:00 URL: https://externals.io/message/93407#93438 · In reply to: #93436 Hi! > The performance effect of this implementation is terrible. > > Assignment to typed property is 2.3 times slower. > Assignment to untyped property in a class with typed properties is 1.8 times slower. > > See the benchmark > https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb800 This is not good. I wonder why these tests weren't made before the vote and results wheren't added in the RFC. Should we make it a standard practice to do so? Having 2x slowdown on each property access sounds like a bad idea. -- Stas Malyshev smalyshev@gmail.com --- ## #93440 — Julien Pauli — 2016-05-23T09:54:41+00:00 URL: https://externals.io/message/93407#93440 · In reply to: #93438 On Mon, May 23, 2016 at 11:09 AM, Stanislav Malyshev wrote: > Hi! > > > […] > > This is not good. I wonder why these tests weren't made before the vote > and results wheren't added in the RFC. Should we make it a standard > practice to do so? Having 2x slowdown on each property access sounds > like a bad idea. The question is : * should the vote be an idea-based vote, or integrate the code into the vote ? My vote did not integrate the code, but the feature. The idea is that if the RFC passes, then the feature is agreed, and we still have some time to find a better implementation. If we could not find one, then the feature should be abandoned or post-poned until a new patch. If the new patch changes the implementation, then the RFC should be reopened. My thoughts. Julien.Pauli --- ## #93441 — Joe Watkins — 2016-05-23T10:16:22+00:00 URL: https://externals.io/message/93407#93441 · In reply to: #93440 Morning internals, I have improved the performance of the patch a little, here's the results of a bad run: krakjoe@fiji:/usr/src/php-src$ sapi/cli/php -n prop.php empty_loop 0.064 write_prop1() 0.088 0.025 write_prop2() 0.079 0.016 write_prop3() 0.082 0.018 ------------------------ Total 0.314 There is going to be overhead, not the kind we can't minimize, or justify though. Dmitry has said he'll review, and I'm hoping at least Laruence, Nikita, and Bob will do the same ... We have many weeks to improve the implementation, I'm not going to merge anything that's obviously bad :) Cheers Joe > On Mon, May 23, 2016 at 11:09 AM, Stanislav Malyshev > wrote: > > […] > times slower. > > […] > > The question is : > * should the vote be an idea-based vote, or integrate the code into the > vote ? > > My vote did not integrate the code, but the feature. > > The idea is that if the RFC passes, then the feature is agreed, and we > still have some time to find a better implementation. > If we could not find one, then the feature should be abandoned or > post-poned until a new patch. If the new patch changes the > implementation, then the RFC should be reopened. > > My thoughts. > > Julien.Pauli --- ## #93442 — Rowan Collins — 2016-05-23T10:32:58+00:00 URL: https://externals.io/message/93407#93442 · In reply to: #93407 > 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 I'm surprised at how popular this RFC has been; not because I think it's a bad thing per se, but I thought it would be more controversial. I do still think PHP should have a proper road map for typing features, though. The issues around typed references in this RFC are a good example of how having an increasing number of silos where type enforcement takes place leads to odd inconsistencies and limitations. It would be nice to have some idea of what the eventual aim is - even if we don't know how yet, is the aim in people's minds for "optional typing" to extend throughout the language? This would also help with performance considerations - if type-checking is going to become a more important concept in the language, the engine should move in a direction which will make that easier, and that may affect optimisation decisions. Regards, -- Rowan Collins [IMSoP] --- ## #93444 — Dmitry Stogov — 2016-05-23T12:38:52+00:00 URL: https://externals.io/message/93407#93444 Hi Joe, Unfortunately your solution with IS_TYPE_VERIFIED is not acceptable, because you update the source zval. If the assigned value is a literal you change read-only memory and crash (with opcache.ptotect_memory=1) a = 5; ?> Thanks. Dmitry. --- ## #93445 — Dmitry Stogov — 2016-05-23T12:48:12+00:00 URL: https://externals.io/message/93407#93445 · In reply to: #93407 Should this work? x = 5; ?> Currently this leads to PHP Fatal error: Uncaught TypeError: Typed property C::$x must be an instance of double, integer used in /home/dmitry/php/php-master/CGI-DEBUG/prop.php:6 --- ## #93447 — Niklas Keller — 2016-05-23T13:46:59+00:00 URL: https://externals.io/message/93407#93447 · In reply to: #93445 Dmitry Stogov schrieb am Mo., 23. Mai 2016 14:48: > Should this work? > > class C { > public double $x; > } > $o = new C; > $o->x = 5; > ?> > > Currently this leads to PHP Fatal error: Uncaught TypeError: Typed > property C::$x must be an instance of double, integer used in > /home/dmitry/php/php-master/CGI-DEBUG/prop.php:6 > Do you mean "float"? > > ________________________________________ > From: Joe Watkins > 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 --- ## #93448 — Dmitry Stogov — 2016-05-23T13:55:18+00:00 URL: https://externals.io/message/93407#93448 Yeah "float". It works :) --- ## #93480 — Dmitry Stogov — 2016-05-24T09:30:51+00:00 URL: https://externals.io/message/93407#93480 After the latest changes the patch became better. From a quick look I see two issues. The following 3 tests are failed (crashed with opcache.protect_memory=1) > Test typed properties float widen at runtime [Zend/tests/type_declarations/typed_properties_027.phpt] > Test typed properties respect strict types (off) [Zend/tests/type_declarations/typed_properties_028.phpt] > Test typed properties unset __get magical magic [Zend/tests/type_declarations/typed_properties_030.phpt] Insignificant white space changes and reformatting should be removed from the patch (this would simplify the review). I'll need to take a deeper look once again, after the opcache compatibility fix. Thanks. Dmitry. --- ## #93481 — Pierre Joye — 2016-05-24T09:40:10+00:00 URL: https://externals.io/message/93407#93481 · In reply to: #93438 > > Hi! > > > […] times slower. > > […] > > This is not good. I wonder why these tests weren't made before the vote > and results wheren't added in the RFC. Should we make it a standard > practice to do so? Having 2x slowdown on each property access sounds > like a bad idea. Agreed. We added a performance impact section to the rfc template for this exact reason. We do not enforce it. Maybe we should. --- ## #93491 — Dmitry Stogov — 2016-05-24T19:04:34+00:00 URL: https://externals.io/message/93407#93491 · In reply to: #93407 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. --- ## #93494 — Joe Watkins — 2016-05-25T06:06:00+00:00 URL: https://externals.io/message/93407#93494 · In reply to: #93491 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 ? 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 ? > 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). If it emerges that the RFC needs to be modified heavily, then I'm happy to stop the voting. 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. 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 > 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 > 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 --- ## #93495 — Dmitry Stogov — 2016-05-25T07:06:17+00:00 URL: https://externals.io/message/93407#93495 · In reply to: #93494 > Morning Dmitry, > > There's no section for nullables, but there is mention of them, > specifically in relation to your query: > > > […] > 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 :) > > > […] > > 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. > > > […] > > 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 > 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 > > 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 --- ## #93496 — Joe Watkins — 2016-05-25T08:30:15+00:00 URL: https://externals.io/message/93407#93496 · In reply to: #93495 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 > > > > > Morning Dmitry, > > There's no section for nullables, but there is mention of them, > specifically in relation to your query: > > > […] > 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 :) > > > […] > > 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. > > > > […] > > 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 > > > > > […] --- ## #93497 — Dmitry Stogov — 2016-05-25T08:36:52+00:00 URL: https://externals.io/message/93407#93497 · In reply to: #93496 > Morning Dmitry, > > > […] > differently... > > I think this is what everyone expects, isn't it ? > > I did omit to mention that part ... > > > […] > should behave. > > It does: > > > […] > 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 > wrote: > > > > > > […] > > It's OK. This just should be defined and it's defined in RFC (I > missed) > > […] > 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. > > > […] > > We are working with Bob, trying to improve the patch. I added new > tests fixing the problems, and also added few comments o github. > > […] > > 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. > > > […] > > I'm not so sure. > Anyway, I hope you are better and we will able to speak today or > tomorrow. > > Thanks. Dmitry. > > > > […] --- Next page: https://externals.io/message/93407.md?page=2