Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91759
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <56ECCFCB.6090105@garfieldtech.com>
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>
	<56ECCFCB.6090105@garfieldtech.com>
Date: Fri, 18 Mar 2016 22:20:52 -0700
Message-ID: <CAMPTd_CWxa7K50fSbYHOEcHvM62YcfcBtZ1Cr392UHkXPsay8g@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11414ee0fb210e052e6006a2
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: walterp@gmail.com (Walter Parker)

--001a11414ee0fb210e052e6006a2
Content-Type: text/plain; charset=UTF-8

On Friday, March 18, 2016, Larry Garfield <larry@garfieldtech.com> wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> C A Horte, the famous computer scientist, calls the introduction of nulls
into his type system (like how Java did it decades later) to be his Billion
dollar mistake. He did it for the mathematical elegance and didn't foresee
all of the null errors that would come. Nulls sound great in theory, in
practice they can be trouble.


Walter


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

--001a11414ee0fb210e052e6006a2--