Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92590
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.41 as permitted sender)
MIME-Version: 1.0
Date: Thu, 21 Apr 2016 19:00:06 +0800
Message-ID: <CAKSD0w4jEH1uRaJ04RsWitV3jdKQxc05eRUxuF3hE8RGSw-nJw@mail.gmail.com>
To: "guilhermeblanco@gmail.com" <guilhermeblanco@gmail.com>
Cc: Dmitry Stogov <dmitry@zend.com>, Tom Worster <fsb@thefsb.org>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c09d9d0eea2d80530fc9cd5
Subject: Re: [PHP-DEV] [RFC] Nullable Types
From: cornelius.howl@gmail.com (Lin Yo-An)

--94eb2c09d9d0eea2d80530fc9cd5
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 20, 2016 at 11:05 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
>
> 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.
>

I think this is not to make PHP like Java, and it totally makes sense -
Nullable should be a type of a type instead of a state. In Haskell it's
named Maybe or Option, and It's better than NullPointerException.

Here is a discussion from Haskell community:
https://mail.haskell.org/pipermail/haskell-cafe/2011-April/091269.html

-- 
Best Regards,

Yo-An Lin

--94eb2c09d9d0eea2d80530fc9cd5--