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
>>
>
>
>
