4

Take an example login() function within a class Account.

class Account {
 /* Class variables */

    public function login() {
        if(isset($_POST['username']) && isset($_POST['password']))
            return $this->_formLogin();
        else if(isset($_SESSION['accountId']))
            return $this->_sessionLogin();
        else if(isset($_COOKIE['username']) && isset($_COOKIE['password']))
            return $this->_cookieLogin();
        else return false;
    }

    private function _formLogin() {
        //perform login actions using $_POST data
    }
    /* All that other stuff */
}

Try for this moment to ignore any concerns about unseen methods for data sanitizing, password salting, and such. Concentrating strictly on login(), is this global access bad juju? I avoid using PHP super globals within classes normally, but I can't think of a good reason not to do it in this situation.

I can understand why you wouldn't want magic-in-the-background occuring with globals interacting across classes, but these globals are built into PHP, aren't modified by the class, and are only used by this class.

It would result in this at the beginning of pages you needed a user logged in on:

$user = new Account($whatever, $objects, $we, $depend, $on);
if($user->login()) {
    //Do this stuff when logged in
}

instead of this on every page, the logic of which may need to be changed later:

$user = new Account($whatever, $objects, $we, $depend, $on);
if(isset($_POST['username']) && isset($_POST['password']))
    $user->formLogin($_POST['username'], $_POST['password']);
else if(isset($_SESSION['accountId']))
    $user->sessionLogin($_SESSION['accountId']);
else if(isset($_COOKIE['username']) && isset($_COOKIE['password']))
    $user->cookieLogin($_COOKIE['username'], $_COOKIE['password']);
if($user->isLoggedIn() {
    //Do this stuff when logged in
}

And while I'm aware that creating a function outside of the class to handle that is an option, wouldn't that be just as bad as obfuscating globals in a class?

Frank Crook
  • 1,466
  • 12
  • 19

4 Answers4

7

To answer my own question, I'd say yes, it's fine to access super globals, provided you aren't modifying them to be accessed across multiple classes. There's no magic going on in the background - you're just reading the state, and super globals are how PHP provides that to you.

However, you should never, ever, ever modify a global within a class and access it somewhere else. That's when you make unit testing impossible.

Frank Crook
  • 1,466
  • 12
  • 19
  • So this question is just you talking to yourself? – cletus Apr 12 '09 at 23:19
  • 1
    @cletus The FAQ tells you to post your answers to your own question using the answer form, and not to put it within your question. If it gets downvoted, I'll know I'm wrong, and with globals giving me an icky feeling, I need some sort of reassurance what I'm doing is right. – Frank Crook Apr 12 '09 at 23:25
  • 1
    "Just reading state" is bad enough. But I agree that reading global state is a lesser evil than writing it. – troelskn Apr 13 '09 at 00:42
7

I wouldn't say there is a straight yes or no answer to this one. What the idea (with all superglobals $_GET $_POST $_SESSION) is that you are asking for data that sits in your entire application, and not local to the scope you are asking for.

What can happen with these superglobals is that what if they change somewhere for whatever reason just before or (god forbid) during the execution of your function. That can turn out to be a very annoying bug to reproduce.

So I would say it is bad form.

Ólafur Waage
  • 68,817
  • 22
  • 142
  • 198
  • +1 Very good point. I never modify super globals, so I haven't been thinking about them being modified elsewhere, and something relying on the data to be the same later. – Frank Crook Apr 12 '09 at 23:41
  • Maybe there's a way to lock super globals so they can't be changed after the script begins? I'll look into that. – Frank Crook Apr 12 '09 at 23:44
2

One approach is to wrap all superglobals into a class of its own. I'm pretty sure Zend Framework has a class of its own for e.g. manipulating Cookies.

Henrik Paul
  • 66,919
  • 31
  • 85
  • 96
0

I would say it depends on your application's design. If the class is some general, loosly coupled class or module and suddenly it uses such global vars, that would be bad practice in my book. But if the class is clearly geared towards a specific task for which those specific global vars are needed anyway (eg your login example), I don't see any clear objections.

Daan
  • 6,952
  • 4
  • 29
  • 36