Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92546
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKSD0w6mg5qfPZ2AexsZLppPi+hHtt9vnW2Zmfsj+A1_AMEtrg@mail.gmail.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>
Date: Wed, 20 Apr 2016 11:05:58 -0400
Message-ID: <CAFp73Xsu-+XC6aVz5Yt08HntyW3NaPm+hJYsPpoxzoqEmvxN1w@mail.gmail.com>
To: Lin Yo-An <cornelius.howl@gmail.com>
Cc: Dmitry Stogov <dmitry@zend.com>, Tom Worster <fsb@thefsb.org>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114026de8a00e60530ebef96
Subject: Re: [PHP-DEV] [RFC] Nullable Types
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--001a114026de8a00e60530ebef96
Content-Type: text/plain; charset=UTF-8

I read the RFC and I want to highlight why I'll vote -1 on it even before
it goes to voting.

IMHO, it looks backwards to what the language is progressing. The
introduction of nullable type hint as a separate notation than a simple
type hint makes it *very* hard to implement typed properties, factory
methods and constructor verifications.

Dmitry is even involved in the discussion of having IS_UNDEF until
constructor ends, then enforcing type hinting at the end of constructor to
trigger potential invalid instance state. It created a mess in the internal
structure by creating a 3-state value: uninitialized, absent of value
(null) and assigned value. All this problem would be solved by merging null
into accepted value.
So far the proposed solution there to take a wrong assumption to assume a
default value based on type defined (like int = 0, string = '', etc), which
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
mailing 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
shouldn't be considered as part of typed properties, but for final
properties (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
what I said and move forward. Congratulations, we just created a language
inconsistency. Example:

function foo(Bar $bar = 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
*reasons*. But accepting the absence of value (null) as a valid value, it
would address the language inconsistency (the current support would be
kept, so no BC break), and would solve a huge mess that typed properties
patch currently needs to solve. Ah, and we don't continue into this path of
madness where 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>
wrote:

> On Mon, Apr 18, 2016 at 4:59 PM, Dmitry Stogov <dmitry@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

--001a114026de8a00e60530ebef96--