Revisiting an earlier post dealing with superglobals and classes, Brandon Savage looks at an example of why its still a bad idea.

I asserted at the time that superglobals inside of a class violated some basic rules on what a class was supposed to do. Today, I am revisiting that discussion. The placement of superglobals inside a class creates an impossible situation for code reuse. [...] Ehat happens when we want to move this [code] to another site? Unless we leave our form fields named [the same] we'll have to modify the original code.

His alternative - a much better refactoring - lets the verifyCredentials method take in the username and password and has the calling script define where those come from, either from a local or global location.