Tuesday, November 18, 2008

Misspelled Variables

Care to guess what happens when you execute the following PHP?
define('FOO', 'Hi');
print(FO);
It prints 'FO'.

I do believe PHP got this from Perl:
perl
print FOO . "FOO"; # Prints FOOFOO
It works even if you're strict:
perl -w
use strict;
print FOO . "FOO"; # Prints FOOFOO
Ruby behaves differently depending on whether you try to print an undefined variable/method or an undefined attribute:
irb
>> print a
NameError: undefined local variable or method `a' for main:Object
from (irb):1
>> print @a
nil=> nil
Python raises an exception:
python
>>> print a
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined
In a compiled language, these sorts of errors would be caught at compile time. However, a compiled language would never let me do something like:
python
>>> var_name = 'a'
>>> locals()[var_name] = 'yep'
>>> print a
yep
This example is a bit contrived, but I've definitely done things like it.

Personally, I like the flexibility of a scripting language. I like it even more when there's a tool like pychecker that can catch these sorts of errors. However, just because a scripting language doesn't have a compilation step that can catch stupid spelling mistakes doesn't mean it should accept them at runtime. I'd much rather deal with an exception than spend half an hour fighting a bug caused by a spelling error!

As a general rule, I think software should fail fast rather than glossing over bugs that will surely cause trouble later. I can handle the exception if I need to, but what I can't handle is a silent bug.

16 comments:

Mike Hansen said...

Your locals() example in Python only works because in the interpreter, you have that

>>> locals() is globals()
True

In general, the locals() is not modifiable in the way that globals() is.

Anonymous said...

Python lint catches this type of error.

Ken said...

it isn't really silent. You'll get an error in your logs:

PHP Notice: Use of undefined constant FO - assumed 'FO' in /data/sites/kai/warn.php on line 3

thowi said...

Variables (scalars) are prefixed by a $ in Perl:

~$ perl -Mstrict -e 'print $FOO . "FOO"'
Global symbol "$FOO" requires explicit package name at -e line 1.

I believe in PHP it's similar.

aflury said...

It's still a valid concern if you're using Perl constants.
$ perl -Mstrict -we 'use constant {FOO => "foo"}; print FO . "bar"'
FObar

Greg said...

Why do you think you could never do:

>>> var_name = 'a'
>>> locals()[var_name] = 'yep'
>>> print a
yep

In a compiled language? Isn't it more a type issue that compiled vs interpreted one?

If the language allows to store variables with different types in a list, I don't see why it won't work.

Mark Hughes said...

In Java:

Point obj = new Point(1, 2);
String varname = "x";
Object x = obj.getClass().getField("x").get(pt);
System.out.println(x); // prints 1


In Objective-C:

id obj = [[[MyPoint alloc] initWithX:1 y:2] autorelease];
NSString varname = @"x";
id val = [obj valueForKey:varname];
NSLog(@"%@", val); // prints 1

Compiled languages are only a problem if they lack true object-oriented features like metaclasses, reflection, and dynamic class loading (i.e., C, C++).

Anonymous said...

The Perl isn't a bug. It is doing exactly what it was designed to do. You are feeding it a list. In your case a list that you concatenate together. Perl "sees" that and good or bad does the assumption that you actually meant to concatenate that together as a list.

my $FOO = 'hello';
print FOO;

Name "main::FOO" used only once: possible typo at p.pl line 2.
p.pl syntax OK

my $FOO = 'hello';
print $FO;

Name "main::FO" used only once: possible typo at p.pl line 2.
p.pl syntax OK

Shannon -jj Behrens said...

> In general, the locals() is not modifiable in the way that globals() is.

Right you are!

Shannon -jj Behrens said...

> it isn't really silent. You'll get an error in your logs:

Yes, but why would I look in the logs if it doesn't show an error on the screen? Do most PHP programmers tail -f their logs in a terminal window while developing? That would make sense, but I've never done it.

Shannon -jj Behrens said...

greg:
>In a compiled language? Isn't it more a type issue that compiled vs interpreted one?

It's not just that I'm storing stuff in a hash, it's that I'm creating new local (or actually global) variables on the fly. In C, you can't read in the name of a local variable from STDIN and then define that global variable on the fly.

Shannon -jj Behrens said...

Mark:
> Compiled languages are only a problem if they lack true object-oriented features like metaclasses, reflection, and dynamic class loading (i.e., C, C++).

Great comment! Yes, reflection and dynamic class loading are two things I love dearly.

Shannon -jj Behrens said...

aflury:
> It's still a valid concern if you're using Perl constants.

Great comment.

anonymous:
> The Perl isn't a bug.

I didn't say it was a "bug". I just disagree with the design decision. I'm glad that the cases you showed work. The case that I showed and the case that Andrew showed don't. Thanks for the comment :)

Shannon -jj Behrens said...

> Variables (scalars) are prefixed by a $ in Perl:

Ugh, silly me. And to think I used to code in Perl! Too many languages leads to too much confusion ;)

Thanks.

Brandon L. Golm said...

IIRC, I think what you are seeing in Perl is that FOO is filehandle portion of the glob *FOO. When you treat this in scalar context, you get its name (which happens to be what you typed).

That way, the following thing works:

$x = FH;
$line = <$x>;

$ perl
print FOO BAR;
Can't locate object method "FOO" via package "BAR" (perhaps you forgot to load "BAR"?) at - line 1.

So it's not being treated as a string. It's just a coincidence really.

Shannon -jj Behrens said...

> So it's not being treated as a string. It's just a coincidence really.

Thanks for setting me straight, Brandon :)