The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I don't think the use of globals in PHP is not always a bad thing. There are instances where it just makes sense. For example the database class in most PHP software is used almost globally in everything.

Well ... you probably picked the worst possible example. A lot of applications have a global named $db. What happens when you want to run two of them together ?

Unless your going to go commercial with your code I see no reason as to why you can't code how you want, uncommented, sloppy, badly formatted, whatever. It usually won't be a problem if its only you looking at it. I can write a several thousand line piece of software without any documentation and still understand the whole thing (since it was a result of my thinking).

Now if your going commercial, I can see why you may want to use better coding habbits.

Never ever assume that you will be the only person who will be reading your own code. Even if the code is in-house, there may be other developers who will be looking at your code in the future.

Even if you are coding for your own personal use alone, you should add some comments or structure your code nicely. It is good practice so get into the habit of doing it. Many years down the road you might need to look at your code again and comments will help you understand what you were doing back then.

Still - I don't ever write code which access said superglobals directly at the application-level. Instead I wrap it in a request-object. Most serious PHP projects does something similar.

This interests me, mind sharing how exactly this is done?

There are tons of ways to get around arduously passing the database connection instance to the constructor.

This part doesn't make a whole lot of sense to me. Most of the superglobals are always set. GET, POST, and FILES are always at least a blank array; even in the CLI they are set. The only one that might not be set is COOKIES, which is only set if the client sends cookies in the request header.

You may be banking on the possibility that this will change in the future, but there's no real evidence of that so you're left with a pre-mature safe guard based on pure speculation. You might as well have just coded it as "true ? $_GET : Array();"

But then again, you do "$this->ENV = $_SERVER;" since $_SERVER is always set, so maybe you're just not aware that GET, POST, and FILES are always set (it's not intuitive since you'd think POST would only be set if the request is a POST).

Actually, I just ran into an issue today, where there was data we needed in a different database than the application's main one, but all the db calls shared a singleton db object. A possible moral to this story could be; never assume you will only every need one instance of an object.

A possible moral to this story could be; never assume you will only every need one instance of an object.

Well, I disagree here. I think you should take into account the nature of the object in order to determine if there could be a need for a second instance. In the case of database connections, it seems obvious to me that while in an early stage almost every web application would likely use just one connection, as soon as you realise there is a probability of the application to grow, the chance you would use a second connection is quite real and therefore using a factory would offer the flexibility you'd need.
However, take an application controller, or an error handler, for example. How many instances would you think you need, despite of the application getting larger? I can only see the need for one of them.

This is for PHP5 right? Could i do something similar using PHP4? I'm not very famiilar with PHP4's OOP capabilities. Took a long break from doing PHP and concentrated on C++, C# and JAVA in college. Used to hate the idea of classes but now i'm seeing its advantages.

PHP4 support is important to me, because most servers still don't provide PHP5... so i can't build a solution which the client's server might not support.

However, take an application controller, or an error handler, for example. How many instances would you think you need, despite of the application getting larger? I can only see the need for one of them.

What on earth is the advantage of doing something like that? What would be the difference of simply running the 2 functions needed upon initialisation and write to the respective variables, and then instead of typing $Http_Request->offsetGet('offset') all over just do $_GET['offset']?

What on earth is the advantage of doing something like that? What would be the difference of simply running the 2 functions needed upon initialisation and write to the respective variables, and then instead of typing $Http_Request->offsetGet('offset') all over just do $_GET['offset']?

What on earth is the advantage of doing something like that? What would be the difference of simply running the 2 functions needed upon initialisation and write to the respective variables, and then instead of typing $Http_Request->offsetGet('offset') all over just do $_GET['offset']?

The superglobals are just as evil as standard global variables, they just sound cooler. Hence they suffer from all the same problems, namely coupling with god knows how many points around the application.

I must admit, I do agree with you - it does seem to overcomplicate things. For me personally it's a matter of consistency and since I always try to push data, never pull it, why should I break that consistency just to pull in from the superglobals and save myself a little time? If nothing else it makes testing so much easier (if I ever write tests, but let's not go there).