Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93506
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 65.55.169.141 as permitted sender)
To: Joe Watkins <pthreads@pthreads.org>, Nikita Popov <nikita.ppv@gmail.com>
CC: PHP internals <internals@lists.php.net>, Phil Sturgeon
	<pjsturgeon@gmail.com>, Bob Weinand <bwoebi@php.net>
Thread-Topic: [PHP-DEV] [RFC][Vote] Typed Properties
Thread-Index: AQHRsl29xlQFrvOFJkSnB4pG0wOhsp/IclufgAC/7gCAAEMjgP//5SuAgABMNACAAAVSAIAAGDdG
Date: Wed, 25 May 2016 14:56:04 +0000
Message-ID: <BY2PR0201MB1784E772EC4052E6453F2A5CBF400@BY2PR0201MB1784.namprd02.prod.outlook.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>
	<CAF+90c9cBqKfy_q5rME1u56Rq366niYUBDTY+3_2iFJSZD9fDA@mail.gmail.com>,<CAL=_i_nrrtsNHMhxeTPxPE4jYyzyWRHQNHVuSp12z8U++ESDhA@mail.gmail.com>
In-Reply-To: <CAL=_i_nrrtsNHMhxeTPxPE4jYyzyWRHQNHVuSp12z8U++ESDhA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BY2PR0201MB1784E772EC4052E6453F2A5CBF400BY2PR0201MB1784_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2016 14:56:04.2124
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1784
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: dmitry@zend.com (Dmitry Stogov)

--_000_BY2PR0201MB1784E772EC4052E6453F2A5CBF400BY2PR0201MB1784_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I thought about a different approach :)


- not-nullable typed properties must be explicitly initialized (or should b=
e initialized implicitly by corresponding types, e.g. "int" should get defa=
ult value int(0). ...)

- nullable typed properties may be implicitly initialized by NULL (like unt=
yped properties now).

- unset() of typed properties should not be allowed


This would allow to eliminate few weird run-time checks in VM and allow the=
 most efficient usage of type information in Optimizar and JIT.


Thanks. Dmitry.

________________________________
From: Joe Watkins <pthreads@pthreads.org>
Sent: Wednesday, May 25, 2016 4:22:02 PM
To: Nikita Popov
Cc: Dmitry Stogov; PHP internals; Phil Sturgeon; Bob Weinand
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties

Morning Nikita,

    That's pretty persuasive ...

    Dmitry, what are your thoughts on those points ?

Cheers
Joe

On Wed, May 25, 2016 at 2:03 PM, Nikita Popov <nikita.ppv@gmail.com<mailto:=
nikita.ppv@gmail.com>> wrote:
On Wed, May 25, 2016 at 10:30 AM, Joe Watkins <pthreads@pthreads.org<mailto=
:pthreads@pthreads.org>> 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.*

I don't agree with this choice, for three reasons:

a) This unnecessarily restricts what can be expressed in the type system. W=
ith these semantics it will no longer be possible to express that a propert=
y should be nullable, but have no default value. This situation is not unco=
mmon in practice, in particular anytime you have a nullable constructor arg=
ument, you will want the corresponding property to be nullable without a de=
fault, to ensure that it is explicitly initialized.

b) This directly contradicts the meaning of ?Type for parameters. For param=
eters ?Type means that it's a nullable parameter **without a default value*=
*. That's the very thing that distinguishes it from the Type $prop =3D null=
 syntax. And now ?Type for properties should mean the exact opposite?

c) If you view this in a larger scope of union types, this *special case* b=
ecomes even more weird. Why does the particular union Type|null get special=
 treatment, while all other unions don't? Or is it actually not specific to=
 "null", but to single value types? E.g. if we also allowed Type|false, wou=
ld that also receive an implicit false default value? What about the type n=
ull|false? Does that get an implicit default, and if so, which? I realize t=
his is not quite in scope for type properties, but the further evolution of=
 the type system should be kept in mind.

Please keep things consistent: If there is not default, there is no default=
.

Nikita


--_000_BY2PR0201MB1784E772EC4052E6453F2A5CBF400BY2PR0201MB1784_--