I went back and read the rest of the stuff on his site, and you're right. He's either talking about Perl without saying so, or is talking in general. The funny thing is that the page you cited could have come right out of a J2EE discussion forum.

I disagree though, that the underlying issue is that using a session object equates to using global state, unless there's some peculiarity with the one he's using. Generally, session objects are kept in a hash keyed by session id, and themselves hold hashes (or the equivalent) for stuffing in session-specific data. Adding data to one session doesn't ipso facto make it available to others. The problem, or one of them, is that session object can become a dumping ground for cruft that isn't garbage collected until the session expires. One can look at that as clogging up the session's namespace, I suppose.

Exactly. Putting stuff in a session object makes it global across a) all your handlers b) all the code in a single handler. As he says, if you're not careful, soon, your pages depend on being called in the right order. Just like with careless use of globals, your functions depend on being called in the right order..

Makeshifts last the longest.

Could you expand on that because I'm just not buying it. To me, session objects are great and I'm happy to use them, but it's important to remember that a session object, like any object, should be limited in scope to what's it's trying to conceptually represent.

For example, it seems reasonable that the object would have the expiration time (tracked in the database and not the cookie) and a user object for representing the user for whom the session is being maintained (again, the key to that would be in the database). Anything else would be superfluous. Thus, it seems to me that the complaints about session objects are actually about using poorly designed objects. Is there something I am missing?

Cheers,
Ovid

Looking for work. Here's my resume. Will work for food (plus salary).
New address of my CGI Course.

To me, session objects are great and I'm happy to use them, but it's important to remember that a session object, like any object, should be limited in scope to what's it's trying to conceptually represent.

That is pretty much the point. I use global variables all the time, too, you know. :-) But they're limited to storing truly global state. So should be session objects. Sigletons are a useful pattern as well; but the same cautions apply.

Just like with globals, singletons, or (in another context) gotos, the problem is not in technique/tool itself, and more in how people commonly use them.

Makeshifts last the longest.