You don't, because it's dumb. Pass the variables you need as arguments to the function at call time and/or use the global keyword to import individual variables into the function scope and/or create new object instances in the body of the function.

Having said that, putting the include statement in the function body should put the files' content in the functions' scope. But really, don't. Rethink your programs' architecture.

You don't, because it's dumb. Pass the variables you need as arguments to the function at call time and/or use the global keyword to import individual variables into the function scope and/or create new object instances in the body of the function.

There are dozens of things that need to be included in the function that can't be preprocessed by the script. To say it's "dumb" is like saying includes are dumb or functions are dumb. It simplifies programming. What's dumb is how PHP handles globals.

Quote:

Having said that, putting the include statement in the function body should put the files' content in the functions' scope. But really, don't. Rethink your programs' architecture.

...says the guy using "dozens" of global variables in the first place? I mean, jesus, have more shared mutable state. Go on! Have it!

Or, if you're feeling like being smart, you can take a moment to consider the possibility (hint: it's more than a possibility) that Schluppy is completely and totally correct and that you are Not Even Wrong in what you're doing. If your super-method needs "dozens" of parameters to do its job, your code is either designed poorly (I can almost guarantee that such a function is doing more work than it should be) and needs refactoring or your data model is designed poorly and you should be centralizing your dependent data in a way that doesn't mean you need "dozens" of separate independent variables to be passed into it. Or both. Always can be both.

What you're doing is widely understood by pretty-much-everyone-ever to be a great way to write terrible code. But, then again...PHP. (Sorry, vherrera. )

You don't, because it's dumb. Pass the variables you need as arguments to the function at call time and/or use the global keyword to import individual variables into the function scope and/or create new object instances in the body of the function.

There are dozens of things that need to be included in the function that can't be preprocessed by the script.

Just to make it crystal-clear: if this sentence is true, your code is fundamentally broken.

ScottSwing: people aren't criticising global state because it killed their puppy, they're doing so because global state increases complexity. The biggest challenge in programming in the large is keeping complexity down. Mutable global state pushes the complexity right up. Now the question is whether it pushes complexity up enough for your head to explode. In my experience, it depends on how complex the rest of the program is. A 20-line test file? I wouldn't hesitate for a moment before using global state. A 20,000,000-line production application used by millions? I'd think a thousand times.

Of course, there are ways to reduce the complexity of global state yet keep the benefits. Here's one way, though I don't see how you could get this in PHP.

...says the guy using "dozens" of global variables in the first place? I mean, jesus, have more shared mutable state. Go on! Have it!

But it's perfectly fine to have them in an include file? The things I need global are part of a security library I downloaded, hundreds of lines of code I don't necessarily want to rewrite if I don't have to.

sid0 wrote:

ScottSwing: people aren't criticising global state because it killed their puppy, they're doing so because global state increases complexity. The biggest challenge in programming in the large is keeping complexity down.

Scope is a good thing. But shouldn't I at least have the option to turn it off when necessary? In Objective-C, I include a file and I can use it in all my methods. Why not here? I'm trying to keep complexity down by writing a function, which PHP is forbidding because I can't access an included file.

I use an external file and everything works perfectly, but all of a sudden I have to inline all of my functions? What sense does that make?

In my experience, it depends on how complex the rest of the program is. A 20-line test file? I wouldn't hesitate for a moment before using global state. A 20,000,000-line production application used by millions? I'd think a thousand times.

The main script is about 20 lines. It's a function I wrote to batch process some data. The function is also recursive so I can't inline it or pass many of the variables to it.

The things I need global are part of a security library I downloaded, hundreds of lines of code I don't necessarily want to rewrite if I don't have to.

ScottSwing, if you could tell us which "security library" you're using or, better yet, post a link to it we may be able to offer you a smarter way to integrate it into your program. Some actual details about what your program does and how you've written it wouldn't hurt either. In other words, post some code so we can see exactly what you're trying to do and you'll probably get some better answers.

The things I need global are part of a security library I downloaded, hundreds of lines of code I don't necessarily want to rewrite if I don't have to.

ScottSwing, if you could tell us which "security library" you're using or, better yet, post a link to it we may be able to offer you a smarter way to integrate it into your program. Some actual details about what your program does and how you've written it wouldn't hurt either. In other words, post some code so we can see exactly what you're trying to do and you'll probably get some better answers.

Tell me why it's okay to include a file, but I'm thenceforth forbidden from using any functions?

It doesn't have access to global variables without explicitly calling for them, which is a good thing because the use of global variables in the manner you are describing is unambiguously bad program design.

It increases coupling and fragility, makes it impossible to reuse or cleanly test the code, and harder to understand (because you have to know what the global variables' sources and values are, rather than just having to see local variables being declared/initialized).

Global state increases complexity and is generally to be avoided when possible.

It increases coupling and fragility, makes it impossible to reuse or cleanly test the code, and harder to understand (because you have to know what the global variables' sources and values are, rather than just having to see local variables being declared/initialized).

Global state increases complexity and is generally to be avoided when possible.

it's really pretty trivial to compare the inherent complexity of global state verses local state.

If you have any set of state comprising N items you have N! possible combinations to consider purely in terms of selecting a few of them at random and deciding if they interact and, if so, how.

in many cases there will be no such linkage (you hope) but still the possibility exists (purely as a name collision issue if nothing else). This problem exists not just in the state machine that is your application, it exists in the minds of all the programmers developing/maintaining it since the person coming fresh to it must ascertain all of this themselves (and woe betide you if something that should have no coupling is deemed to be acceptable for such use by a new member).

If you _prevent_ such coupling from taking place by making state aggressively localized to where it matters you not longer have N! combinations, you have a series of (if well designed) much smaller things all of which are still factorial but, one hopes each one waaaay smaller. So long as, as your system grows you keep separation of concerns you should be looking at something like (N / (N-a))! * N/b for some a which is pretty small and b which is hopefully reasonably close to log(N). That should result in state which is understandable.

Just because you have made something local rather than global is no panacea, if you go an take some dependency on the result of a function with local state such that you care about how a bit of state within it is maintained you can still have coupling (of the very worst kind) but designing it this way tends to discourage such things.

If all your state is global you have nothing but N!. That's a *huge* number for anything but really trivial N...