> I agree with the first replier: If spelling out your variable names is too tedious (and it probably would be too tedious for me), use hashes. That's what they're for. And they can have nice short names.

Too slow. :-)

> Your code is a marvelous example of the danger of such approaches. Your code could easily break if someone were to add to the database a column that has the same name as an existing variable in your program!

I appreciate the wake-up call, but consider this:

my($field1, $field2, $field3);
$sth->prepare("SELECT Field1, Field2, Field3 ...");
$sth->bind_columns(\($field1, $field2, $field3));
while($sth->fetch) {
    print "$field1\t$field2\t$field3\n";
}
[download]

Versus:

my($field1, $field2, $field3);
$sth->prepare("SELECT Field1, Field2, Field3 ...");
$sth->bind_columns(map { \$$_ } @{ $sth->{NAME_lc} });
while($sth->fetch) {
    print "$field1\t$field2\t$field3\n";
}
[download]

In both situations, our would-be saboteur has to add a field variable to the my() list, a field name to the SELECT list, and then add the output command. If that doesn't hammer the point home that the variable name is reserved, I doubt one more step (adding the same field to the list of binded variables) is going to make much of a difference.

I guess the point I'm trying to make here is that there's more than one way to do it... and there's more than one way to break it. In-line comments and self-documenting code (ie, I did not use a SELECT *, the field list was explicitly defined) are really our best tools in fighting "ignorance". Any script can be easily broken in any number of ways.

Besides the fact, my proposal to use a separate package name gets around this problem. :-) Other than, of course, someone using the same package name. But I think it's safe to assume that a programmer experienced and confident enough to be creating packages like that will at least take a look around to make sure the package is being used. This is where documentation and commenting comes in handy!

Thanks for your insight.

Alakaboo