Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92419
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.42 as permitted sender)
To: Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
References: <D33531D4.6D3F3%fsb@thefsb.org>
 <CAFMT4NqGa=mKUksczpe6HepjM1Wthsw9dY7dX3JBWO9xB-FLJA@mail.gmail.com>
 <D3357498.6D41E%fsb@thefsb.org>
 <CAFMT4NrN=q1ZBUXGBPquFTVVaJpoHfbhTDKU2LMZY1C5tu4FKg@mail.gmail.com>
 <D335A5AA.6D579%fsb@thefsb.org> <57103A46.6040803@garfieldtech.com>
 <CAFMT4NpOCf3VON01_3n4xMKVOhEVNL-CsRm5gYOgogEnwt=XvQ@mail.gmail.com>
 <5710BA79.5060108@lsces.co.uk> <57110DC5.8000007@garfieldtech.com>
 <571338E6.50507@fleshgrinder.com> <57145AF7.7060607@garfieldtech.com>
 <57149405.2040701@lsces.co.uk> <57151210.7040704@garfieldtech.com>
Message-ID: <57152641.7050602@gmail.com>
Date: Mon, 18 Apr 2016 11:24:01 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <57151210.7040704@garfieldtech.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Nullable Return Type Declaration
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> I am not sure what you're implying by "some people have no appreciation
> of the usefulness of"... I am well aware of NULL's use cases.  I am also
> well aware that the general zeitgeist in the language development
> community is that they're dangerous; the designer of the first language

I would like to note in general that following the latest fashion in
academic development is not always a good idea for PHP. It's fine when
you experiment with academic languages, but when you have language that
a) focused on simplicity and low entrance barrier and b) is in
production use by millions and has 20 years of existing practices,
libraries and habits, we have to be a bit more wary, I think. I am *not*
saying we should not improve, or ignore academic developments, I am
saying that we should be careful with not jumping to the idea-of-the-day
bandwagon too fast, before it is clear it is good and necessary for PHP.

As an example, I don't see how exactly eliminating null would be good
for PHP, or doing *anything* with null for that matter.

> to have them calls them a "billion dollar mistake", many languages
> actively avoid having NULL in favor of something deliberately more
> structured.  NULLs are a very common cause of avoidable fatal errors in
> many languages (including PHP). NULLs are rude to users of your API, as
> it balloons the error handling code they need to deal with.

I think this description is misleading in a way. Nulls are immediate
causes of many errors, technically, in a meaning that "if I find null
where I expected to have DB connection, I get an error" - but this is
only a technical cause. The *real* cause is the failure to check whether
your attempt to connect to the database succeeded, or that you have
proper DB configuration, or such, and null is just a symptom of that
error - and that error is not automagically fixed by having some other
object instead of null. You have to actually design and write code for
it, there's no replacement for it.

So declaring null "cause of all evils" is ignoring the real causes and
blaming immediate technical cause instead, and it would not be helpful.
It is true that for some languages with more complex type systems it is
possible to largely get rid of nulls by using those complex types and
ensure type system controls for all checks at least to be present (note
that doesn't guarantee proper function either, since no type system can
ensure you handle the case of missing DB connection properly, it just
can ensure you have a branch for it). But that requires much more
complex and involved type system that PHP has - or, in my opinion,
should have.

> I am on record and will continue to be on record that null is *usually*
> wrong.  I consider that position entirely justified, as does the
> academic CS community.  I am also now on record suggesting that we use
> union types to allow type-or-null returns/parameters, which you're
> welcome to quote me on. :-)

I think this position is way too narrow, simplistic and detached from
real language use towards abstract academic purity. There are tons of
causes where using null is completely fine and exactly what is needed. I
also think union types is a great and unnecessary complication of the
language and in order to do them properly we'd need lots of facilities
PHP does not have (like type pattern matching and static compilation)
and I am not sure it should have - ones looking for Haskell know where
to find it.
And there are a lot of cases where failing on null is exactly what one
needs - if it doesn't work, just fail and let somebody come and check
what is going on. If your database died, your DB-bound code is not going
to fix it. With or without nulls - it has to just fail and wait for
somebody to fix it. There's no need to overcomplicate that.
-- 
Stas Malyshev
smalyshev@gmail.com