Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91758
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error)
To: internals@lists.php.net
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <CADyq6sKRFA667RA8Uzcx8SZ9x+GMEvoiX8S7QqrfV-fh0qgrGg@mail.gmail.com>
 <CADyq6sJxUrTQu__mQv-649cyvg4htzG+VK5g400b5-Vrvs5+TQ@mail.gmail.com>
 <56EC69EF.1090003@fleshgrinder.com>
Message-ID: <56ECCFCB.6090105@garfieldtech.com>
Date: Fri, 18 Mar 2016 23:04:27 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56EC69EF.1090003@fleshgrinder.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: larry@garfieldtech.com (Larry Garfield)

On 03/18/2016 03:49 PM, Fleshgrinder wrote:
> First a general note on the complete nullability first: It is not up to
> us as language designers to decide whether it is good practice to use
> nullable properties or not. It is supported by many systems since ages
> (e.g. SQL where nullable fields are also not recommended but heck they
> are useful) and it is common practice in PHP. Hence, there must be
> support for it. That does not mean that it is endorsed in any way by us,
> it is just there for people who need it for the same reasons they needed
> it in the past 20 or so years.

At the risk of a small tangent, I cannot agree at all here.  The whole 
point of language design is to make decisions regarding what "good 
practices" to encourage, enforce, or disallow.  Some languages disallow 
mutable variables (despite them being useful).  Some languages disallow 
global variables (despite them being occasionally useful).  Some 
languages disallow NULLs (despite them having use cases in many 
languages).  Those are all viable and reasonable decisions for a 
language designer to make in various circumstances; to say that it's 
"not up to us as language designers" to make such decisions is to 
abdicate our responsibility as language designers.

There may well be good arguments to allow property nullability. There's 
also good arguments against it.  We'll decide one way or another.  But 
"we shouldn't take a position at all" is worse than taking a position, 
because that implicitly does take a position (allowing it), while 
pretending that we didn't.  Basically it means lying to ourselves about 
it, which is never the right answer.

Design is about making deliberate, informed decisions.  Let's make a 
deliberate, informed decision.

To help with the informed part, can anyone speak to how other languages 
handle null-typed properties?  I believe Java allows everything to be 
NULL (which sucks), but I'm not sure about other modern languages.  Can 
anyone speak to that?  (I'd be particularly interested in Python, Go, 
and Rust, but any language you can speak to definitively would be 
valuable to know about.  Javascript and Ruby are, AFAIK, insufficiently 
typed for the question to apply.)

--Larry Garfield