Lord Yggdrasill wrote:But yeah, I agree that it technically does not make much difference other than making the code looks clear, professional and more readable.
Granted, this is subjective, but my point is that this lack of a real difference is precisely why the use of a wrapper would not provide any real advantage in clarity (and hence readability). However, if you are using a wrapper class with the idea of asserting greater control over the session interface so that you can be more resistant to an API or even a requirements change, then by all means, go ahead.
By the way, would you please stop throwing around the word "professional", especially when you are implying that code written in a procedural manner is less "professional"? Otherwise, I might suggest the use of say, Java instead of PHP to be more "professional" 😉
Lord Yggdrasill wrote:If there is a way to actually make better use of a session wrapper class so it does more useful jobs(rather than just convert traditional procedural code to OOP way), Id like to hear.
Well, not only is a session typically a store with global state, it is also a very simple key/value store. No point turning the simple into something complicated when you don't need to.
But if you want to follow up on what I wrote in post #4, something useful is to throw an exception if an attempt is made to access a session variable that does not exist. This ensures that such an error cannot be casually ignored, and allows for certain code to be written in an "easier to ask for forgiveness than permission" manner.
