Re: [RFC][Vote] Typed Properties
| From: | Dmitry Stogov | Date: | Wed, 25 May 2016 08:36:52 +0000 |
| Subject: | Re: [RFC][Vote] Typed Properties | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-93497@lists.php.net to get a copy of this message | ||
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 <dmitry@zend.com <mailto:dmitry@zend.com>> wrote:While parameters allow null to be accepted as the defaultOn 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:
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 JoeOn Tue, May 24, 2016 at 8:04 PM, Dmitry Stogov <dmitry@zend.com <mailto:dmitry@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.phptI'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 <pthreads@pthreads.org <mailto:pthreads@pthreads.org>> Sent: Friday, May 20, 2016 9:05:34 AM To: PHP internals; Phil Sturgeon Subject: [PHP-DEV] [RFC][Vote] Typed PropertiesMorning internals,Since we have our answer on nullable types, typed properties can now go to vote.https://wiki.php.net/rfc/typed-properties#voteNote that, support for nullability as RFC'd will be merged when the implementation for nullable_types is merged into master.Please participate.Cheers Joe