|
Re^2: I've been bit in the neck by open()
by blazar (Canon) on Feb 16, 2005 at 14:38 UTC
|
As a side note, I wonder wether perl could emit a warning when one tries to open() an anonymous file for reading (or for writing) only... or are there common situations in which it could be desirable to do so?
Perl doesn't warn on deliberate features, whether common or not. Perl autovivifies undefined filehandles, and array and hash references, and allows you to do my $var; $var += 3; without warning as well. They are all features.
Sorry, but you misunderstood what I meant, or maybe I didn't express myself clearly.
I'm not referring to autovivification et similia in general, of which I am aware too and that I consider to be great features myself as well.
I am referring to a particular, "special" open() feature, and in particular that of opening an an anonymous FH when it is passed undef as a third argument with the three-args form of call.
You'll notice that the example given in the doc itself is with mode '+>', that it says one can also use '+<' instead, but it gives a warning about it.
The cmt I made was about opening such anonymous files in '<' (or '>') mode, which could have a sense if the FH is subsequently duplicated, but which is likely, IMHO, not to be what the average user would want in the first place...
| [reply]
[d/l]
[select] |
|
|
I am referring to a particular, "special" open() feature, . . .
You're complaining that a poorly-known, but well-documented, feature of open() doesn't throw a warning when you accidentally trip over it. Ok ... I can buy that.
I think the real discussion needs to be whether or not there should be a warning when opening an anonymous filehandle. That's a fair discussion to have. Unfortunately, you're probably going to be Warnocked if you post to p5p about this. They tend to frown upon making changes that violate the Principle of Least Surprise.
You might be able to do something yourself with warnings::register and overriding CORE::open(), but that may be more trouble than it's worth.
Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply] |
|
|
You're complaining that a poorly-known, but well-documented, feature of open() doesn't throw a warning when you accidentally trip over it. Ok ... I can buy that.
Well, not really, in fact I wrote:
As a side note, I wonder wether perl could emit a warning when one tries to open() an anonymous file for reading (or for writing) only...
and if you look at the emphasized text you'll notice that I meant to ask for some user consideration about this issue, rather than claiming that a warning should be there and then complaining for there not being. It's a meditation after all... but the only one who addressed directly that cmt (an anonymous monk) completely missed my point!
I think the real discussion needs to be whether or not there should be a warning when opening an anonymous filehandle. That's a fair discussion to have.
Personally I do not think that there should be, and that is not what I meant.
The keyword (well, "keyphrase") in my original cmt is not "anonymous filehandle", but "for reading only". In fact I do think that that anonymous filehandle feature of open() is great, and as you wrote, it's well documented. OTOH the documents literally say:
As a special case the 3 arg form with a read/write mode and the
third argument being "undef":
open(TMP, "+>", undef) or die ...
opens a filehandle to an anonymous temporary file. Also using
"+<" works for symmetry, but you really should consider writing
something to the temporary file first. You will need to seek()
to do the reading.
Notice that it doesn't even mention that anonymous filehandles can be opened in modes other than '+>' and '+<'.
Now, follow me: why should one want to open an anonymous (temporary) filehandle? To store something in it and then to retrieve it. But if you open it '<', then you'll get an empty anonymous file to read from. What can you do with it? Apart from interacting with the filesystem, appearently nothing!! Now, this is not strictly true, as this example code shows:
#!/usr/bin/perl
use strict;
use warnings;
open my $fh, '<', undef or die $!;
open my $fh2, '>&=', $fh or die $!;
select $fh2; $|++;
print "foo\n";
seek $fh, 0, 0;
print STDOUT <$fh>;
__END__
But you'll agree that it's rather awkward. It could make more sense to open it in write-only mode and then re-open it in read mode later when needed to retrieve what's been stored into it...
Unfortunately, you're probably going to be Warnocked if you post to p5p about this. They tend to frown upon making changes that violate the Principle of Least Surprise.
Yep, I think you're right. But then again this was just a meditation... | [reply]
[d/l]
[select] |
Re^2: I've been bit in the neck by open()
by RazorbladeBidet (Friar) on Feb 16, 2005 at 13:21 UTC
|
allows you to do my $var; $var += 3; without warning as well.
That's interesting. I would have figured it would warn of an uninitialized variable.
This was all I could find:
Use of uninitialized value%s
(W uninitialized) An undefined value was used as if it
were already defined. It was interpreted as a "" or a 0,
but maybe it was a mistake. To suppress this warning
assign a defined value to your variables.
To help you figure out what was undefined, perl tells you
what operation you used the undefined value in. Note,
however, that perl optimizes your program and the
operation displayed in the warning may not necessarily
appear literally in your program. For example, "that $foo"
is usually optimized into "that " . $foo , and the warning
will refer to the concatenation (.) operator, even though
there is no . in your program.
What is the reasoning behind this? | [reply]
[d/l] |
|
|
sub unique {
my %seen;
$seen{$_}++ for @_;
keys %seen;
}
my @unique_values = unique( @some_values );
While it's not the best or most efficient way, it is the standard way to extract the unique elements from an array. Do you really want N "uninitialized variable" warnings where N is the number of unique elements in your array?
And, that's just one common usage.
Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply]
[d/l] |
|
|
To be honest, yes, if I've requested warnings.
But this is probably just a philosophical divide. I often get mixed feelings about languages that require initialization versus assumptions. One day I like one, the other day I like another :-D
I assume there's some measure of consistency, though. I guess what I'm really wondering is - where is that line?
| [reply] |
|
|
|
|
|
|
| [reply] |
|
|
What is the reasoning behind this?
Programmer convenience. Remember that Perl is there to serve the programmer - not the other way around. Anytime you have to do something for the sole reason of not triggering a warning, you've not been productive. Warnings should not get in the way - the more warnings there are that give false positives, the more likely it is warnings are ignored, or shut off completely. (As any security or ergonomics expert can tell). Wanting to do += (or .=) on undefined values is common enough to not have a warning emitted. Beside the example given, here's another:
$sum += $_ for @list;
Note that Perl is smart enough to figure out that having undefined values for *= or /= is probably a mistake, and it warns then. | [reply]
[d/l] |