in reply to Re: Variable variable names
in thread Variable variable names

Here's one of the summaries from the last of mjd's articles: 
    One of the biggest problems in all of compter
    programming is namespace management and data
    hiding. When you use a symbolic reference you are
    throwing away forty years of expensive lessons from
    the School of Hard Knocks.

[download]
The fact is, a hash in my opinion buys you much larger than a "fractional" benefit w/r/t blowing away your variables. Why do you want to mix up your form values with variables in your application? What are you *gaining* by doing that?

You give the example of a variable called $name: 

    Because it's a CGI, it is very unlikely that I'll want
    to use a "$name" variable somewhere else for
    some purpose other than sucking in the "name"
    element as in my example.

[download]
Sorry, but $name isn't a very good example of an uncommon variable name. :) That's the sort of thing that could very easily get you in trouble if your programs start getting larger, or if you start doing development in a team environment, etc.

The basic point here is: you're buying yourself nothing, save typing a couple of characters, by not using a hash. Even if you view using a hash as providing only "fractionally" more security, why not use it?

Replies are listed 'Best First'.
RE: RE: Re: Variable variable names
by Trimbach (Curate) on Oct 24, 2000 at 05:07 UTC
    All good points, but remember that it's a CGI, which means I am (by definition) stuck with that pesky HTML form and those form elements. I want to confuse my element names with my application variables... one way of looking at it is a deliberate, controlled extension of my application's namespace to include the HTML form.

    I'm not saying that using a hash is a bad idea, but I do think that we should be very careful in our choice of dogma. Perl, far more than most languages, is not a black and white affair. I challenge the dogma that "all soft references are bad" by presenting a reasonable situation where some programmer somewhere might choose to use them to advantage.

    Gary Blackburn
    Trained Killer

[reply]
      I want to confuse my element names with my application variables... one way of looking at it is a deliberate, controlled extension of my application's namespace to include the HTML form.
      And the day someone returns a form variable that happens to overwrite your value of $authorized with 1 for a critical application, you are toast. This already generated a CERT warning for a PHP application... why repeat history with Perl when it is so easily avoided?

      In the security biz, we repeat two mantra:

      • Do not let your data become code.
      • Do not let your code become data.
      The wise one pays attention to both, with rigor.

      -- Randal L. Schwartz, Perl hacker

[reply]

In Section Seekers of Perl Wisdom