Well, in the example I give, the variable is only used briefly on (essentially) one page so (to prevent session variable runaway) you'd have to register and unregister the session variable and you'd also have to get the multi-select results in and out of the variable every time the page was accessed (which would generally happen consecutively anyway). This way after that initial construction you don't actually have to write any more code.
First, you didn't give an example. For example, this is the example that you should have presented:http://news.devnetwork.net/test.php?value
Secondly, there is a reason I suggest using Sessions for this as the prefered method.
First, you don't have to register or unregister a session variable. Simply doing
$_SESSION['var'] = 'value';
And that's it. In many cases, you may not be able to easily access the URL's being used on your website.
Also, you make the (wrong) assumption that the user will follow the path you have presented him.
For example: In a recent form I did, rather than simply pass the variable through, I save them in a session. Why? Because if the user leaves the form to go someplace else, and then comes back, I want that information there.
Another reason is potential security. The more information you open up, the more potential problems you invite.
I am not saying your way is bad. Rather, I am saying that I feel your approach, while different, isn't the best. solution.
I don't get why you guys are so pessimistic about this - in the situation I describe alone it seems to me that it is a neat trick and fairly obviously the most efficent (code wise at least) way of dealing with it. And it's really quite a common situation.
Pessimistic? I guess my definition of pessimistic is different from yours. I don't see anyone being pessimistic. Rather, I see people questioning your methods, which isn't pessimistic. It's healthy.
If anyone, myself included, came on the board, and started talking about a new encryption method they invented called rot26 (=)), would you expect everyone to just say: Oh hey! Let's be sheep and just agree.
I wouldn't. Rather, I would expect people to question the person presenting the method. Not because we are out to get anyone. Rather, we have these honest questions about this solution.
If your only response to these questions is "why are you guys so pessimistic about this," then sorry, but that doesn't help your case. It's akin to me saying "Why don't you guys see how cool rot26 is! It's so obvious for me!"
Great, it's obvious for you. But that doesn't mean a damn thing in the real world. Explain WHY you think your idea is better.
Several statements, conclusions, that you have presented are final. And yet you do nothing to back up these claims. Let's take a look at your claims.
"in the situation I describe alone it seems to me that it is a neat trick"
You never gave an example of what your talking about. Rather, you just presented an overview, and nothing to backup your claims. Also, it's been my experience that "neat tricks" are simply that, and nothing more, and rarely productive.
"fairly obviously the most efficent (code wise at least)" way of dealing with it."
Are you sure? Efficient in what way? Is it robust? Secure? Fast? The less lines of code you have doesn't mean it's more efficient. I can think of several reasons why your idea isn't the most efficient, and yet you haven't presented any reasons why your idea is efficient.
"And it's really quite a common situation."
I am going to go out on a limb here and assume that I have more years coding PHP then you. I've never really run into the problem you present.