Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92556
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 157.56.110.106 as permitted sender)
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>, Lin Yo-An
	<cornelius.howl@gmail.com>
CC: Tom Worster <fsb@thefsb.org>, internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Nullable Types
Thread-Index: AQHRlf/HRrhz9JlaLkGvYOd79l/iMp+JStcAgAH+hYCAAAhNm4AAiDUAgAOa/k2AAHy3AIADDrcAgAARXdw=
Date: Wed, 20 Apr 2016 16:13:31 +0000
Message-ID: <BY2PR0201MB178494E8EF85885D7AB287E6BF6D0@BY2PR0201MB1784.namprd02.prod.outlook.com>
References: <CAFMT4No6yFJ4r4bWGOaLZkYdpqE_YeDiEHCecq4ATBqypeUegQ@mail.gmail.com>
 <570F4BB4.6020709@zend.com> <57112225.6020905@thefsb.org>
 <BY2PR0201MB1784002A8F5F1D577220BD5BBF680@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <57119B5E.6070205@thefsb.org>
 <BY2PR0201MB178497F586633AA99AD8E00ABF6B0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CAKSD0w6mg5qfPZ2AexsZLppPi+hHtt9vnW2Zmfsj+A1_AMEtrg@mail.gmail.com>,<CAFp73Xsu-+XC6aVz5Yt08HntyW3NaPm+hJYsPpoxzoqEmvxN1w@mail.gmail.com>
In-Reply-To: <CAFp73Xsu-+XC6aVz5Yt08HntyW3NaPm+hJYsPpoxzoqEmvxN1w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BY2PR0201MB178494E8EF85885D7AB287E6BF6D0BY2PR0201MB1784_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2016 16:13:31.7151
 (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] Nullable Types
From: dmitry@zend.com (Dmitry Stogov)

--_000_BY2PR0201MB178494E8EF85885D7AB287E6BF6D0BY2PR0201MB1784_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

What we really miss now, is an ability to define nullable return types.


https://wiki.php.net/rfc/nullable_return_types


I don't care about the same notations for arguments (and everything else), =
because we already may use NULL default value.

However usage of "?" for arguments also may make sense. Someone may like th=
is, someone not.


Thanks. Dmitry.

________________________________
From: guilhermeblanco@gmail.com <guilhermeblanco@gmail.com>
Sent: Wednesday, April 20, 2016 18:05
To: Lin Yo-An
Cc: Dmitry Stogov; Tom Worster; internals
Subject: Re: [PHP-DEV] [RFC] Nullable Types

I read the RFC and I want to highlight why I'll vote -1 on it even before i=
t goes to voting.

IMHO, it looks backwards to what the language is progressing. The introduct=
ion of nullable type hint as a separate notation than a simple type hint ma=
kes it *very* hard to implement typed properties, factory methods and const=
ructor verifications.

Dmitry is even involved in the discussion of having IS_UNDEF until construc=
tor ends, then enforcing type hinting at the end of constructor to trigger =
potential invalid instance state. It created a mess in the internal structu=
re by creating a 3-state value: uninitialized, absent of value (null) and a=
ssigned value. All this problem would be solved by merging null into accept=
ed value.
So far the proposed solution there to take a wrong assumption to assume a d=
efault value based on type defined (like int =3D 0, string =3D '', etc), wh=
ich are all potential valid values, leading to unpredictable behavior if a =
develop misses to assign a value to that property.

Sure, people will say that now PHP will require a NullPointerException, PHP=
 is turning into Java, or that I don't know what I'm talking about because =
they coded for Amiga and I don't (yes, I've seen that already in this maili=
ng list). But the fact is that keeping control of 3-state flags are hard to=
 maintain.

Constructor verifications is actually a completely different subject that s=
houldn't be considered as part of typed properties, but for final propertie=
s (or whoever other keyword someone think is smarter because *reasons*). It=
's bad to bring this already to typed properties, specially because of its =
runtime performance impact.

Now let's say we move forward with nullable type hint, ignore everything wh=
at I said and move forward. Congratulations, we just created a language inc=
onsistency. Example:

function foo(Bar $bar =3D null);

Why now I have 2 ways to define a nullable value? Shouldn't this be changed=
 into this:

function foo(?Bar $bar);

But of course, changing this would be a BC break and should be left for *re=
asons*. But accepting the absence of value (null) as a valid value, it woul=
d address the language inconsistency (the current support would be kept, so=
 no BC break), and would solve a huge mess that typed properties patch curr=
ently needs to solve. Ah, and we don't continue into this path of madness w=
here same thing have 144 different ways in different areas to be defined.


Regards,

On Mon, Apr 18, 2016 at 12:24 PM, Lin Yo-An <cornelius.howl@gmail.com<mailt=
o:cornelius.howl@gmail.com>> wrote:
On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov <dmitry@zend.com<mailto:dmit=
ry@zend.com>> wrote:

> The grammar is taken from HHVM.
> Using any other would make more mess.
>
I agree



--
Guilherme Blanco
Lead Architect at E-Block

--_000_BY2PR0201MB178494E8EF85885D7AB287E6BF6D0BY2PR0201MB1784_--