Care to guess what happens when you execute the following PHP?
I do believe PHP got this from Perl:
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.
define('FOO', 'Hi');
print(FO);It prints 'FO'.I do believe PHP got this from Perl:
perlIt works even if you're strict:
print FOO . "FOO"; # Prints FOOFOO
perl -wRuby behaves differently depending on whether you try to print an undefined variable/method or an undefined attribute:
use strict;
print FOO . "FOO"; # Prints FOOFOO
irbPython raises an exception:
>> print a
NameError: undefined local variable or method `a' for main:Object
from (irb):1
>> print @a
nil=> nil
pythonIn a compiled language, these sorts of errors would be caught at compile time. However, a compiled language would never let me do something like:
>>> print a
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined
pythonThis example is a bit contrived, but I've definitely done things like it.
>>> var_name = 'a'
>>> locals()[var_name] = 'yep'
>>> print a
yep
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.
Comments
>>> locals() is globals()
True
In general, the locals() is not modifiable in the way that globals() is.
PHP Notice: Use of undefined constant FO - assumed 'FO' in /data/sites/kai/warn.php on line 3
~$ perl -Mstrict -e 'print $FOO . "FOO"'
Global symbol "$FOO" requires explicit package name at -e line 1.
I believe in PHP it's similar.
$ perl -Mstrict -we 'use constant {FOO => "foo"}; print FO . "bar"'
FObar
>>> 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.
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++).
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
Right you are!
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.
>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.
> 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.
> 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 :)
Ugh, silly me. And to think I used to code in Perl! Too many languages leads to too much confusion ;)
Thanks.
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.
Thanks for setting me straight, Brandon :)