Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91747
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
To: internals@lists.php.net
References: <CABDNdAHwgx+LJRc_gi9citiypxxWVGFMB+6hrmU+vVYDWCDV_g@mail.gmail.com>
 <56EA8EA9.80905@mprelu.de>
 <CAPhkiZx+ckh0gMc8gh7LiEVQj1TLQPR2R8adbO_LL8hPvJ3eHw@mail.gmail.com>
 <CAGa2bXahQQgeWC3J_Ryradm7CYde_RgRFBDkUEsQ875PbWObZA@mail.gmail.com>
Message-ID: <56EBE919.6090103@lsces.co.uk>
Date: Fri, 18 Mar 2016 11:40:09 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <CAGa2bXahQQgeWC3J_Ryradm7CYde_RgRFBDkUEsQ875PbWObZA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC Discussion] Typed Properties
From: lester@lsces.co.uk (Lester Caine)

On 18/03/16 10:55, Yasuo Ohgaki wrote:
>> Although I'm all for limiting NULL to only being the default value:
>> >
>> >     $this->name = null; // this should throw a TypeError
> NULL is special type. '' and NULL is different entity.
> 
> class User {
>   public string $username = NULL;
> }
> 
> After authentication $username could be "yohgaki". What is should be
> after logout? $username = '' does not make sense, but $username =
> NULL.
> 
> There are ways to work around this, but property cannot be NULL is
> problematic. IMO.
> 
> class User {
>   public string|null $username = NULL;
> }
> 
> may work. I'm not sure if this is good idea in general.

While I understand why some people think 'typed variables' are the bees
knees, we have also had the debate on the relevance of 'NULL' as a key
element of data management. Data validation goes far beyond 'it's an
integer' and a default value which is NOT '0' is just as likely as one
that is as is a return from a database that gives 'NULL' for fields that
are not returned in the sub-joins of a query. Making the 'its and
integer' a special case does not remove the need to then validate that
the integer returned is actually valid, or perhaps taking a different
program path if a NULL value has been returned.

All I see most of the additional magic code doing to my creating a
usable copy of an array of database entries is adding more delays to
actually viewing the data. As a example, if I look up an individual
record on a family tree, returning a 'null' identifier for the father
link is correct and we don't then load that object. Making the database
return an empty string or a 0 depending on how your identifier is
structured is a complication that is not necessary, as is returning
typed values for data that has not yet been established such as birth
date or age.

Now if we are adding a proper validation layer then including a variable
type makes sense, but just doing part of the job for some bits that may
or may not actually be usable?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk