Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88289
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.170 as permitted sender)
To: internals@lists.php.net
References: <CAKws9z27kVJ87Ur5Qo+ayYHPeeO=aYKpRHUV4TFBXX2iMcgO2A@mail.gmail.com>
 <E1C02A1A-EB7C-40D9-8760-13627CC7BF85@craigfrancis.co.uk>
 <9AF329EC-99A5-412D-A52B-432627A5520F@gmail.com>
 <6F4D91EE-B56E-4B83-B1AF-598C3F6897FC@craigfrancis.co.uk>
 <55F07BA4.2000204@gmail.com>
 <E8634CF1-C2B4-4C5A-8DDC-531D9599774B@craigfrancis.co.uk>
 <55F6B911.9080400@gmail.com>
 <96BE7F01-D04B-483B-B1A3-B45CED6DFCDC@craigfrancis.co.uk>
 <55F6F08C.1020506@gmail.com>
 <0BEF6D82-CB5F-49F6-A3A4-3267924A0CDA@thesba.com>
 <55F72CA9.2060301@gmail.com>
 <09369945-76FE-4E08-9C2C-15FB0577AD27@thesba.com>
 <55F752E7.9070801@gmail.com>
 <D062C4F7-B56E-422F-A563-C7C4A16D36B0@thesba.com>
 <55F9B4C7.3050700@gmail.com>
 <440C64A2-4B4F-4AEF-ACE3-F3A6637EBAB6@thesba.com>
 <55F9D704.5050002@lsces.co.uk>
 <FD9ABCC5-E928-4810-AE1A-E1DC7E0FB3D1@gmail.com>
 <55F9EFA2.9020908@lsces.co.uk>
 <0022A1D9-DC37-4F49-B58E-FBED5AF872BA@gmail.com>
 <55F9FAB3.2050100@lsces.co.uk> <55FB19CB.7080707@gmail.com>
 <55FB3117.5040204@lsces.co.uk>
Message-ID: <55FB3A60.1040601@gmail.com>
Date: Thu, 17 Sep 2015 23:10:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55FB3117.5040204@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: rowan.collins@gmail.com (Rowan Collins)

On 17/09/2015 22:31, Lester Caine wrote:
>> To paraphrase, your 3 states being communicated from the controller to
>> the view are:
>> a) Do not use this object, even if you want to.
> EG Vehicle is not old enough to need MOT
>
>> b) If you want this object, you may create a default one.
> EG No current MOT found
>
>> c) If you want this object, create it with these parameters.
> EG Display date of MOT ... when next one due should not be stored here,
> only when one is added.

This is an entirely arbitrary mapping. You actually have two pieces of 
information you're trying to fit into one variable:
- the MOT status, out of "not needed", "no current MOT", "has current MOT"
- the details of the current MOT, if one exists

That's what I was getting at with my "variable colours" example - if all 
you're after is "a variable with 3 states, one of which also allows a 
value", that's not really anything to do with exists() and isset() any 
more. It would be a convenient use of that state, except that that state 
isn't convenient to use, so why try?

This is also a perfect example of why co-opting states like null and 
unset for complex meanings is generally a bad idea: what if in future, 
you need to distinguish a 4th case of "never had an MOT"? You've now 
used up both NULL and !exists(), so you're back to square one, and need 
to petition for some other piece of variable metadata to be exposed - or 
give up and change the implementation to use a separate state flag.


>> You then want to use null for case (b), so need a "very null" value
>> (non-existent variable) for case (a).
> Database takes care of managing the business logic to ensure data is
> consistent. One could use an invalid date for 'NULL' but these are not
> consistent between database engines ... NULL is. Reading CAR data does
> not return an 'MOT' record while it is not needed. 'MOT' does not exist
> flags logic to display 'first MOT due' from registration date. Putting a
> date in the 'MOT' field is not the way to handle that.
>
> The business logic in decent databases like Oracle and Firebird rely on
> NULL for many reasons, and while one can return more fields to handle
> the 'three state' model, NOT returning a field is faster. MOT is crude
> example, on council systems several sets of data may interact, and the
> NULL state is significant.

You keep defending your use of NULL, but that is not what needs 
defending; it is the proposed use of an unset variable as a "very null" 
state which I am questioning. As far as I know, most databases do not 
have the notion of "does not exist" in tables or result sets - the 
result of a Left Join failing is the same type of Null as can be stored 
in a Nullable column.

Regards,

-- 
Rowan Collins
[IMSoP]