Jump to content

Recommended Posts

The function only acts as a convenience, there is no real benefit other than that.  In my opinon, if you use extract you will loose track of where your variables come from.  When I am coding I prefer to know whether it is a POST, SESSION, COOKIE, SERVER or GET variable whenever and wherever I use it.... unless I am creating a new variable with arithmetic purposes....

 

Such as 

$e = pow(($_POST['m'] * $_POST['c']), 2);

Edited by Zane

I wouldn't advise its use for $_POST or $_GET. In this case you may just as well have register_globals enabled (not recommended).

 

However, when it comes to something like

$row = mysql_fetch_assoc($result)
extract($row);

 

then it is far more convenient to

 

echo "$id<br>";

 

than

 

echo "$row['id']<br>";

I use it for my template system.  Code a bit like:

function DoTemplate($__file, $__vars){
      extract($__vars);
      include($__file);
}

DoTemplate('somefile.tpl', array(
   'title' => 'blah'
   , 'desc' => 'Some description'
));

 

Then in the template file I can just use the key names directly as variables:

<html><head><title><?php echo $title; ?></title></head>
<body>
  <h1><?php echo $title; ?></h1>
  <p><?php echo $desc; ?></p>
</body>
</html>

I would only recommend it when you know the scope of what variables will be created/overwritten (kicken's example usage) or use it with one of the option flags/prefix that prevents overwriting existing variables.

 

What happens if you have a pagination script that sets up a variable named $page (or any other variable a script might be using - $user, $id, ...) and at some time in the future you or someone else working on the project needs to add a column named page to a database table or the column id in your table isn't the same meaning as the exiting $id variable? Using extract on the data from the query just broke your script and you now have to troubleshoot (or remember) exactly where each variable is being set at.

Personally I don't use it because I think it reduces the readability of the code. I like to clearly be able to identify where a variable came from. In the past I have worked with code that used extract() when fetching data from a database. While I can certainly see that it is convenient to use it in this situation, it also makes me - as a reader of the code, not the writer - have to check the column names of the query to see if they match a certain variable. Otherwise I'd have to figure out it has been injected into the current script somehow. To me the convenience does not justify the cost of readability, but maybe that's just me. :)

To expand on PFMaBiSmAd's answer:

 

I would recommend not using it at all. If you really feel the need to use it, use the EXTR_PREFIX_ALL flag. This way you don't overwrite any existing variables, and the prefix can make it obvious where the variable came from:

 

$row = mysql_fetch_assoc($res);

extract($row, EXTR_PREFIX_ALL, 'DB_');

echo 'UserID: ' . DB_id;

Here's an example where using extract on a database query result would open a security hole.

 

What if you have a database table search form on your page that is open to sql injection (it's only selecting data from your product/blog/news table after all, how dangerous could that be to your code?) By injecting SELECT ... 'value' AS some_variable_name ... the extract() statement would cause php to do this - $some_variable_name = 'value'; This just allowed someone to set your $loggedin, $admin, $user_name, $user_id ... variable in your code to any value they wanted.

 

A person looking to save some typing by using extract is also likely to leave out escaping data being put into a query statement.

Edited by PFMaBiSmAd
This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.