Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88317
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.174 as permitted sender)
To: internals@lists.php.net
References: <CAKws9z27kVJ87Ur5Qo+ayYHPeeO=aYKpRHUV4TFBXX2iMcgO2A@mail.gmail.com>
 <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>
 <55FB5BA6.6050606@lsces.co.uk>
Message-ID: <55FBF265.5000502@gmail.com>
Date: Fri, 18 Sep 2015 12:15:49 +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: <55FB5BA6.6050606@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)

Lester Caine wrote on 18/09/2015 01:32:
> On 18/09/15 00:14, Rowan Collins wrote:
>> 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'.

Whether or not you use "Select *", all the rows in the result set have 
the same number of columns, surely?


>
>> 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.

Sure. I was thinking more that your example mapped those 3 states rather 
arbitrarily onto 3 domain states that you wanted to model; if you 
happened to want to model 4 states, this technique wouldn't be any help.


>>> 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.

My point was that if you use isset() in place of is_null(), you don't 
have to switch off any errors. That's the only difference between the 
two functions - that isset() doesn't raise a notice if the variable 
doesn't exist.


>>> 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.

Huh? All I meant was, asking to deprecate extract() is like saying "I 
can't use an object as an array key, so we might as well get rid of 
associative arrays" - just because you can't use it in the way you'd 
like, doesn't mean it's useless.

(That said, I'd personally be happy to see PHP lose extract(), and 
variable-variables, and the $GLOBALS array - but it's pretty unlikely.)

Regards,
-- 
Rowan Collins
[IMSoP]