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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
