Michael Fowler wrote:
>
> On Wed, Sep 20, 2000 at 03:25:11PM -0700, Steve Fink wrote:
> > > > complains, but
> > > >
> > > > $x = 3; $x = 3
> > >
> > > As it shouldn't; you've mentioned $x twice, which means you probably didn't
> > > misspell it. That your mentioning twice in this manner is silly is beyond
> > > perl's grasp.
> >
> > Actually, it isn't. I've often written $x = $x = 3 simply to avoid this
> > warning, because in the current implementation perl can't several of the
> > different ways of using a variable.
>
> Which is silly, because you shouldn't have to say '$x = $x = 3' when you
> mean '$x = 3'. Just because there's a real reason behind it doesn't make it
> any less silly.
Ok, I can't argue with that. :-)
> > But I think you're missing the point. Why would you assign a value to a
> > variable, but then never use that variable's value? All typos would be
> > caught by the "initialized but never used" warning, as well as other
> > mistakes.
>
> So, in the code:
>
> $foobal = 3;
> if (@ARGV) {
> $foobar = @ARGV;
> }
>
> print $foobar;
>
> Only warn me that $foobar is uninitialized? I always prefer it when the
> actual source of my problem is pointed out, rather than its symptoms.
It's exactly the same behavior as now, if you add in the "maybe it's a
typo?" guess. Which sounds fine to me.
> > > Whoa, are you saying that saying 'my $x' no longer means $x has the value
> > > undef? What value does it have? How can this be a good thing?
> >
> > No. No semantics change. This RFC is... what's the opposite of
> > far-reaching? It changes no semantics. It only adds warnings. 'my $x'
> > still means $x's value is undefined (but please do not say "the _value_
> > undef").
>
> I'm saying the value undef now, because that's exactly what it is, now. I
> have learned that 'my $foo' is an implicit 'my $foo = undef', for all
> intents and purposes.
And undef is short for the function call undef(), which could be
implemented
sub undef {
my $var;
return $var;
}
(except undef can optionally take parameters, as in undef $x)
Something that isn't defined() means that either nobody bothered to
assign a value to it, or somebody took away its value.
> > my $x;
> > ...some code that might set $x to some value...
> > if (defined ($x)) { ... }
> >
> > is bad, but
>
> This is an idiom I use all the time, and I don't see anything wrong with it.
> The value is undef, and I don't want to see this change at all.
>
> > my $x = undef; # or my $x; undef $x;
>
> I just have to say, ick. 'my $x' is easy, 'my $x = undef' is slightly
> annoying. 'my $x; undef $x;' is confusing; declare a variable, and then
> immediately undefine it, so I can avoid uninitialized value warnings?
> Blech. What of a list of declarations, 'my($foo, $bar, $blah)'? do I get
> lots of warnings unless I assign undef to, or undef, all of those?
Yes. Note that I wasn't suggesting that anyone "should" use C<my $x;
undef $x;> over C<my $x=undef>, it's just more clear given that undef is
a function call.
With my style of programming, my($foo,$bar,$blah) would rarely trigger
warnings, because I would do something with those variables before using
them. I rarely use defined() to mean "if the control has happened to
take a route that never affected the values of this variable". In those
cases, I wouldn't mind using an explicit undef.
It sounds like your style of programming is different. So you wouldn't
enable those warnings. And also that you find the existing warning
useful, which means the control over the warnings must be more
fine-grained than all or nothing. Sounds reasonable to me. And you might
want to temporarily turn on full warnings mode, ignore the spurious
messages, fix the bugs uncovered, and turn the warnings back off.
The question is whether there are enough people who use either my style
of programming or want the temporary warnings firehose to warrant
implementing it. I haven't been able to determine yet whether this is
the case. People largely ignored this RFC when it first came out.
> I never particularly liked this feature of C, that a variable had junk in it
> naturally until you assigned something to it. I much prefer how Perl does
> it; give it a sane value, but warn whenever that value is used unless it was
> intentional (by using defined or conditionals).
No argument there. But do you like the feature of C where it warns you
at compile time when this is going to happen?
> > Perl's runtime specifically tracks variables and expressions whose value
> > is undefined, and does it well enough that most people think of 'undef' as
> > being just another value.
>
> It is just another value AFAIK, PL_sv_undef.
That's implementation. The semantics are determined by the effects of
various operations on objects whose values are undefined. And those
effects reveal that it isn't just another value; no other value behaves
anything like it.
