Ovid,
You gotta pick your battles. This is undoubtedly a misleading (and often incorrect) error message. I think (and hope) that it would be difficult to find someone who disagrees with that. But "thoroughly irked"? That's when you need to pick your battles. XML::Twig crashing perl5.6 - that is thoroughly irksome. CGI::Session not saving the session because the only thing that changed was an expiry - that is irksome (but probably not thoroughly irksome). A misleading error message? That's something to open a formal bug report on (does p5p use a bugzilla or something?), take a deep breath, drink some nice tea, beer, or other beverage of choice, and move on. ;-)
| [reply] |
| [reply] |
I am aware of this and thoroughly irked by it. It would certainly be nice if Perl could disambiguate between the two. As it turns out, there might be information in perl about that, but there doesn't seem to be much interest in fixing this.
Currently the internals of Perl can't be used to distinguish between an uninitialised value and a merely undef one. To make the core do so would involve adding an extra flag to all SVs and adding code to about every fourth line in sv.c
to set or unset it as appropriate. And for very little gain.
Okay, the warning is misleading: it's warning about the use of an undef value rather than un uninitialised one. We would change the warning text, but then that would probably break half the test suites on CPAN and everyone would hate us for it.
Dave.
| [reply] |
undef is how Perl designates that a variable is uninitialized. undef $var is how you declare that the variable is no longer initialized. $var= undef does the same thing.
If you try to disinguish 'undef' from 'uninitialized', then you'd need a new way to deinitialize variables and an alternative for defined that would tell you if a variable was initialized.
undef and defined are just Perl's methods of introspection about whether a variable is initialized. It is good that you can explicitly mark a variable as uninitialized and that you can programmatically check for initialization. Marking a variable as uninitialized can look like initializing the variable.
I agree that using "uninitialized" instead of "undefined" in error messages is unfortunate. But they mean the same thing in Perl.
| [reply]
[d/l]
[select] |
tye, you're just picking the nits in a different way. And, to be honest, I've never thought about "undef" as "uninit". In more general computer science terms, I would expect:
my $t; # perl
int* pi; // C/C++
to be uninitialised. But I would expect:
my $t = undef; # perl
int* pi = NULL; // C/C++
to be initialised but not really usuable. The fact that perl guarantees that uninitialised variables are undef allows the semantics you're arguing for, that they mean the same thing in perl, but that just seems to be an accident due to a feature.
I don't think I would really be in favour of having the perl runtime distinguish between undef and uninitialised - that's just more code to run in lots of places, and would likely break another feature of perl: autovivication. Just as simply assigning to $h{blah} will create the blah key, shouldn't using $a automatically initialise ... to undef? IMNSHO, fixing the error message is sufficient. And all that would break is the test suite for perl itself ... and a few other modules that catch warnings and respond to them (in other words, I understand why it's not being fixed).
What we probably should be doing is giving our error messages and warnings a prefix tag that our code can look for instead. Rather than "Use of uninitialized value in ...", why not "PERL0183W: Use of uninitialized value in ..."? With the latter, we can change the text all we want, as long as the prefix stays the same. All tests, signal handlers (for __WARN__ and __DIE__), and $@ checks could simply look for /^PERL0183W:/, and text changing won't affect them. I realise that the majority of error and warning messages won't change. But by having it as a standard for all internal messages, we won't need to worry about the ones that do need change.
NOTE: if the original post had "use diagnostics", it would tell you that "an undefined value was used as if it were already defined." Then this whole thread might have been averted, and I would not have had to tell Ovid to calm down ;-} | [reply]
[d/l]
[select] |
The fact that perl guarantees that uninitialised variables are undef allows the semantics you're arguing for, that they mean the same thing in perl, but that just seems to be an accident due to a feature.
No, I'm pretty sure that Perl guarantees that uninitialized variables are undef because that was the point of undef and defined and having a warning for trying to get a string or number from undef. The point was to offer ways of tracking uninitialization. That is why, when the person was writing the text for the warning for "you used undef" pulled out the word "uninitialized", because that was the concept motivating the whole exercise.
| [reply] |