Makes sense, depending on how far you trust the user. If you come up with a technique that can set a named variable, a saavy malicious user could set *any* named variable, if he guesses it correctly. If you have a variable named $datafile that points to a file to read, what if he sends "data__/etc/passwd" or what have you? Even worse, "data__|rm -rf . *"?

You could solve two problems in one swoop by sticking every settable variable in a hash. You have to know the hash keys to access the values (so they're available), and if you only allow the hidden fields to modify pairs in the hash, it's a lot harder to do nasty tricks like above.

On the other hand, you could use Apache::Session or a related technique, saving the data on the server temporarily, and passing only a session key or unique identifier on the hidden field, not serializing your data to hidden fields in HTML. I'd take this last approach, because I don't trust the clients to *type* the right thing, let alone send back correct data.