Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88304
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: <CAKws9z27kVJ87Ur5Qo+ayYHPeeO=aYKpRHUV4TFBXX2iMcgO2A@mail.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> <55FB3A60.1040601@gmail.com>
 <55FB4270.7000204@lsces.co.uk> <55FB4969.7080600@gmail.com>
Message-ID: <55FB5BA6.6050606@lsces.co.uk>
Date: Fri, 18 Sep 2015 01:32:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <55FB4969.7080600@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 7.1 - Address PHPSadness #28?
From: lester@lsces.co.uk (Lester Caine)

On 18/09/15 00:14, Rowan Collins wrote:
> On 17/09/2015 23:45, Lester Caine wrote:
>> The 'does not exist' requires that there IS a second field to carry the
>> flag that 'MOT' is not required, while simply leaving it out of the
>> result set then saves two fields.
> 
> I'm confused - do you mean that some rows in the result set from the
> database have columns "missing", rather than just set to NULL? That's
> not something I've ever come across before.

While it would be better SQL practice to list all fields used in the
result set, '*' will return 'all fields' which are visible and may
indeed have 'missing fields'.

> By the way, you still haven't addressed my point about this whole setup
> only giving you 3 states, and there being no particular reason you won't
> need a 4th later.

For this particular method of working which is perhaps 20 years old,
there are only three states. If the field exists in the result set, if
it's null and if it has a value.

>> Currently one has to switch off errors where is_null may be used with a
>> non-existent field
> 
> Why? That's what isset() is for, which is where this whole discussion
> started; I'm not sure why you've suddenly mentioned is_null().

But the whole problem here is that isset does NOT identify that the
result set has fields that are NULL. The point everybody has been making
is that we need something that returns true for isset AND is_null,
unless you have some other method of identifying that the variable
exists before calling is_null ?

>> Deprecate expand() so it's use is not possible may be another 'fix'?
> 
> Surely there are plenty of ways to use extract() without attempting to
> give meaning to missing variables.

So similarly there are plenty of ways of using null field variables if
extract() has created them.

-- 
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