Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93498
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.161.172 cause and error)
MIME-Version: 1.0
In-Reply-To: <26b6c4c1-5af0-b2f1-f308-1b6dc973cf3a@zend.com>
References: <CAL=_i_mcJoFnPgeU5FQCJN=SDYnNK7Jz8zoVMv9EMuWaGRYSMg@mail.gmail.com>
	<BY2PR0201MB17845690B6386D75AF4C3D79BF4F0@BY2PR0201MB1784.namprd02.prod.outlook.com>
	<CAL=_i_=EqNoHvXmY+RdQW-reC4YF8AkuWFtGGJGOOSqX4a010g@mail.gmail.com>
	<cfe8404a-54f6-24b7-0ba8-8f807c820821@zend.com>
	<CAL=_i_kze8MNSmpg4WT+EJCRPmvty=8DA6DkuHSx+WCBzJjytg@mail.gmail.com>
	<26b6c4c1-5af0-b2f1-f308-1b6dc973cf3a@zend.com>
Date: Wed, 25 May 2016 09:48:11 +0100
Message-ID: <CAL=_i_=ZYuRyYai57B_2u-FwidgFoTV1caYJkim6ZS17DMjrzw@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: PHP internals <internals@lists.php.net>, Phil Sturgeon <pjsturgeon@gmail.com>, 
	Bob Weinand <bwoebi@php.net>
Content-Type: multipart/alternative; boundary=001a1143f4f6c4fda50533a6bb1e
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: pthreads@pthreads.org (Joe Watkins)

--001a1143f4f6c4fda50533a6bb1e
Content-Type: text/plain; charset=UTF-8

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 <dmitry@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 <dmitry@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 < <dmitry@zend.com>
>> 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.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 < <pthreads@pthreads.org>pthreads@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
>>>
>>
>>
>>
>
>

--001a1143f4f6c4fda50533a6bb1e--