4

tl;dr: Is there a way to prevent alteration to (essentially lock) variables declared/defined prior to an include() call, by the file being included? Also, somewhat related question.


I'm wondering about what measures can be taken, to avoid variable pollution from included files. For example, given this fancy little function:

/**
 * Recursively loads values by include returns into
 * arguments of a callback
 * 
 * If $path is a file, only that file will be included.
 * If $path is a directory, all files in that directory
 * and all sub-directories will be included.
 * 
 * When a file is included, $callback is invoked passing
 * the returned value as an argument.
 *
 * @param string $path
 * @param callable $callback
 */
function load_values_recursive($path, $callback){
    $paths[] = path($path);
    while(!empty($paths)){
        $path = array_pop($paths);
        if(is_file($path)){
            if(true === $callback(include($path))){
                break;
            }
        }
        if(is_dir($path)){
            foreach(glob($path . '*') as $path){
                $paths[] = path($path);
            }
        }
    }
}

I know it's missing some type-checking and other explanations, let's ignore those.

Anyways, this function basically sifts through a bunch of "data" files that merely return values (typically configuration arrays, or routing tables, but whatever) and then invokes the passed callback so that the value can be filtered or sorted or used somehow. For instance:

$values = array();
load_values_recursive('path/to/dir/', function($value) use(&$values){
    $values[] = $value;
});

And path/to/dir/ may have several files that follow this template:

return array(
    // yay, data!
);

My problem comes when these "configuration" files (or whatever, trying to keep this portable and cross-functional) start to contain even rudimentary logic. There's always the possibility of polluting the variables local to the function. For instance, a configuration file, that for the sake of cleverness does:

return array(
    'path_1' => $path = 'some/long/complicated/path/',
    'path_2' => $path . 'foo/',
    'path_3' => $path . 'bar/',
);

Now, given $path happens to be a visible directory relative to the current, the function is gonna go wonky:

// ...
if(is_file($path)){
    if(true === $callback(include($path))){ // path gets reset to 
        break;                              // some/long/complicated/path/
    }
}
if(is_dir($path)){                          // and gets added into the
    foreach(glob($path . '*') as $path){    // search tree
        $paths[] = path($path);
    }
}
// ...

This would likely have bad-at-best results. The only1 solution I can think of, is wrapping the include() call in yet another anonymous function to change scope:

// ...
if(true === call_user_func(function() use($callback, $path){
    return $callback($path);
})){
    break;
}
// ...

Thus protecting $path (and more importantly, $callback) from causing side effects with each iteration.

I'm wondering if there exists a simpler way to "lock" variables in PHP under such circumstances.

  1. I just wanna go on the record here; I know I could use, for instance, an elseif to alleviate one of the issues specific to this function, however my question is more interested in circumstance-agnostic solutions, a catch-all if you will.
Community
  • 1
  • 1
Dan Lugg
  • 20,192
  • 19
  • 110
  • 174
  • Namespacing won't solve your problem? Since 5.3 PHP's miserable namespacing got better and usable...barely. – Adam Arold Nov 04 '11 at 22:43
  • @edem - While I have taken full advantage of most features available 5.3+, namespaces is one I haven't adopted; I can't quite visualize how that would help under these circumstances either. – Dan Lugg Nov 04 '11 at 22:56
  • What is up with all of the **tl;dr:** references lately? – Jared Farrish Nov 04 '11 at 23:46
  • @Jared Farrish - From me, or in general? I only did it because after re-reading my question, I realized it was quite verbose for what it was asking, and rather than erase the details I should summarize. – Dan Lugg Nov 04 '11 at 23:56
  • The best approach is just to be straight forward and state your problem, and say more information follows. Leave the message speak to text messages. `:)` – Jared Farrish Nov 04 '11 at 23:59
  • Don't know, if I get it right, but wouldn't it be much simpler to just avoid using global variables at all (as its recommended anyway)? – KingCrunch Nov 05 '11 at 00:07
  • @KingCrunch - I avoid using "global" variables as most savvy developers do when possible; I don't believe this is any different. Where did you get globals from? – Dan Lugg Nov 05 '11 at 00:19

2 Answers2

1

take a look at Giving PHP include()'d files parent variable scope it has a rather unique approach to the problem that can be used here.

it amounts to unsetting all defined vars before the include and then resetting them after.

it certainly isn't elegant, but it'll work.

Community
  • 1
  • 1
Allain Lalonde
  • 91,574
  • 70
  • 187
  • 238
  • Thanks @Allain Lalonde - Yea, that's something I've considered; the most elegant solution so far is the one I've used so many times before; that is, wrapping whatever in a self-invoking anonymous function to create a new scope, and `use()` in what you need. I think I may have asked a question before, inquiring if it was possible to unset a `$path` variable simultaneously used as an argument for `include()`, but to no avail. This seems to be the only alternative though. – Dan Lugg Nov 05 '11 at 00:22
1

I've gone with the following solution to include pollution:

$value = call_user_func(function(){
    return include(func_get_arg(0));
}, $path);

$path is nowhere to be seen at inclusion, and it seems most elegant. Surely, calling func_get_arg($i) from the included file will yield passed values, but, well...

Dan Lugg
  • 20,192
  • 19
  • 110
  • 174
  • I've received a **-1** on both this answer and another using a similar method to answer the question http://stackoverflow.com/a/8376780/409279; I'm left to assume it's from the same individual. Would you care to elaborate on why? I'm curious for a better alternative, and surely you must know one. – Dan Lugg Dec 04 '11 at 18:46
  • Obviously from beelzebub because you are a MODERN DAY SAINT! – lol Jul 19 '13 at 11:58
  • yeah that's good! but 100% agree that stack overflow needs to force comment with down votes! – lol Jul 20 '13 at 06:22
  • @lol I don't think Stack Overflow needs to force commenting on a downvote; however, if you see something wrong I think it's more constructive to leave a comment whether you downvote or not. Otherwise it's just like quietly turning off the light and leaving the room unannounced. It's subjective, so 'meh'. – Dan Lugg Jul 20 '13 at 12:54