Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88247
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.46 as permitted sender)
To: internals@lists.php.net
References: <CAKws9z27kVJ87Ur5Qo+ayYHPeeO=aYKpRHUV4TFBXX2iMcgO2A@mail.gmail.com>
 <55E5EBBF.6020803@gmail.com>
 <0BA3A129-D356-4781-B6DE-E2B5A7924AE2@craigfrancis.co.uk>
 <55E6EC36.6090301@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> <55F78D90.7090601@php.net>
 <55F7CE3E.1040804@lsces.co.uk> <55F93E67.3000806@gmail.com>
 <55F945F7.8010402@lsces.co.uk> <55F94B25.8070603@gmail.com>
 <55F95439.5070306@php.net> <55F95F26.5080409@gmail.com>
 <55F963E7.2040800@php.net> <55F9668F.4010804@gmail.com>
 <55F96DF5.8030606@php.net> <55F96F02.2080601@gmail.com>
 <55F9889F.1060008@lsces.co.uk>
Message-ID: <55F98D81.6010109@gmail.com>
Date: Wed, 16 Sep 2015 16:40: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: <55F9889F.1060008@lsces.co.uk>
Content-Type: text/plain; charset=windows-1252; 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 16/09/2015 16:19:
> Found the little gem I was trying to remember ... extract()
> Import variables into the current symbol table from an array
> THAT was the process I've seen used in libraries resulting in 'NULL'

Yes, extract(), like variable-variables ($$foo), can dynamically create 
local variables, and therefore lead to cases where you don't know, until 
runtime, whether a variable exists at all.


> I appreciate this is all very far
> fetched, since one could check things on the array side, but it is where
> I've seen mistakes with handling the generated variables

Indeed. Until Craig's template / View example, I'd never seen extract() 
actually used for anything remotely defensible, but it is there, so it's 
a fair question whether we consider it a "bad" function in some way.

My inclination is that even if you're using such a mechanism to 
dynamically define variables, it would still a bad idea to write code 
like this:

if ( exists($a) ) {
...
} elseif ( is_null($a) ) {
...
} else {
// use $a
}

There is clearly a lot of hidden meaning here - what exactly are the 
three states of the variable representing, in domain terms? - which 
would be better exposed with another variable or something. For 
instance, if we make $a an object, you might instead write this:

if ( $a->is_dummy_data() ) {
...
} elseif ( $a->is_system_default() ) {
...
} else {
// use $a->value
}

If the extract() was being used to make the view code more readable in 
the first place, the exists() defeats rather than assists in that 
objective, in my opinion.

Regards,
-- 
Rowan Collins
[IMSoP]