Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^2: Falling for the same trap - since 1942

by Aristotle (Chancellor)
on Jul 14, 2003 at 11:29 UTC ( #273947=note: print w/replies, xml ) Need Help??


in reply to Re: Falling for the same trap - since 1942
in thread Falling for the same trap since 1942

Well, since the guy who wrote that is in my Perlmongers group and I got the link from following a discussion on our mailing list, I feel qualified to say he is talking about any dynamic web programming. And though irrelevant to the point at hand, at least his current job is a Perl based ecommerce site. At any rate, his point is that the session object represents a global namespace. And we know what happens when you try to stuff the variables for every scope of your program into a single namespace.

It's as simple as that.

Actually, if you browse the directory above that article, you'll find a number of other short articles on web programming that I found quite insightful, esp in how he questions and rejects a few other common practices in this subject area as well.

Makeshifts last the longest.

  • Comment on Re^2: Falling for the same trap - since 1942

Replies are listed 'Best First'.
Re: Re^2: Falling for the same trap - since 1942
by dws (Chancellor) on Jul 14, 2003 at 16:25 UTC
    Well, since the guy who wrote that is in my Perlmongers group and I got the link from following a discussion on our mailing list, I feel qualified to say he is talking about any dynamic web programming.

    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.

Re: Re^2: Falling for the same trap - since 1942
by Ovid (Cardinal) on Jul 15, 2003 at 00:11 UTC

    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://273947]
help
Chatterbox?
and the shadows deepen...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (6)
As of 2018-05-23 09:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?