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