Re^6: Warnings on unused variables?

close will never fail, cause all we want to do is create the file.

In this situation, yes. This may not be true later.

But that's a dozen of characters of unnecessary code. For just one line of code! I'd have useless code all over the place. Code that can do nothing but introduce errors, since it doesn't serve any function.

No, you shouldn't need it more than once, because that's a corner case you can stick in a procedure. The final close serves the function of making missing filehandles visible elsewhere.

Since you believe in closing everything explicitly, the warning won't help you there.

Careful, that's not what I said. I believe in making sure that every variable that was intentionally not used gets used in such a way that it is marked, even via an unnecessary close call, exactly because it allows you to catch errors like this by turning on warnings::unused:

open(my $fh1, '>', $file1) or die;
open(my $fh2, '>', $file2) or die;
for (@data)
{
   print $fh1 "$_\n";             
   print $fh1 "$_\n";   # Oops, but detected, because $fh2 will exit u
+nused
}
[download]

Where you are correct is in situations where I do need to check the output of the close, because I'm worried about disk space limitations or other issues. As soon as I have to check the output of close on all the variables, warnings::unused stops protecting me. That's unfortunate, but it's no reason not to use it, especially since you have just kindly pointed me at autodie, which I had not seen before, and looks very handy, and will allow me to avoid the very problem you just pointed out.

You've never used threads? And constructors are routinely called names other than new.

Please allow me to rephrase: I won't write constructors without obvious construction names. And yes, I consider the object creation via obscure call a problem, not a feature, of Perl. I wouldn't mind a warning for blessing a reference inside a method that didn't at least start with 'new', 'create', or at the very least, 'gen'. Or some global variable declared up top, so it's not such a burden on non-English speakers. Just something consistent.

You say deallocation of resources on block exit worthy of a warning? Every single variable in Perl does that!

No, a simple deallocation of resources wouldn't have required you to lodge everything in a constructor/destructor that way. You're refcounting from copies made in methods, or doing something else subtle. Since it's obviously not simple, it's nice to have a warning that the block is going to end with something complex.

That's not to say that this is always the rule. I brought up slews of special-purpose destructor objects, for instance (though frankly, that probably indicates that something needs to be better grouped), and Corion brought up the fair counterpart argument to that (though he didn't emphasize it, which surprised me), which is many-returns closing one or two destructors with special features, but attached to an object with no other function but to manage them. It's not something I'd expect to see often, but I'm willing to listen to the argument that they're really, really common, and I'm just not in the right circle to see it. So far, though, I'm not seeing any other convincing arguments that strewing one-shot declarations all over the code with hidden functions is actually the clearest way to solve a problem.

I'd rather avoid doing away with exceptions, I'd rather my code doesn't throw spurious warnings

Well, we obviously have a fundamental philosophical disagreement about what is spurious. It may not be important; I'm not sure a discussion of warning philosophy warrants exclamation points and so much node space, but I'll offer you this: if you can show me a code formation that is plausibly frequently found in a project, raises warnings under warnings::unused, and any changes that would result in the warnings going away also results in the code becoming significantly less clear or maintainable, I'll concede the point and try not to bring it up again. We can play code tennis: you post something that warns, but is otherwise clear, and I try to make it clearer and warning-free. Writing code can be fun (and I do intend to follow up on your question about the behaviour of warnings::unused in different scenarios, because it is code). This kind of essay isn't, really, so otherwise, since I'm obviously not in a position to mandate anything in the development of Perl 6, let's leave it at that.

Comment on Re^6: Warnings on unused variables? Download Code

Replies are listed 'Best First'.
Re^7: Warnings on unused variables? by ikegami (Patriarch) on Sep 28, 2008 at 00:41 UTC
No, a simple deallocation of resources wouldn't have required you to lodge everything in a constructor/destructor that way. Sorry, but that's all that those two examples did. You're refcounting from copies made in methods, or doing something else subtle Really, no. One released OS resources, the other released Perl resources by breaking cyclic references. Well, we obviously have a fundamental philosophical disagreement about what is spurious That's been my point all along. You're enforcing style, and thus a warning turned on by `-w` or `use warnings;` is not appropriate.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^7: Warnings on unused variables?
by ikegami (Patriarch) on Sep 28, 2008 at 00:41 UTC

No, a simple deallocation of resources wouldn't have required you to lodge everything in a constructor/destructor that way.

Sorry, but that's all that those two examples did.

You're refcounting from copies made in methods, or doing something else subtle

Really, no. One released OS resources, the other released Perl resources by breaking cyclic references.

Well, we obviously have a fundamental philosophical disagreement about what is spurious

That's been my point all along. You're enforcing style, and thus a warning turned on by -w or use warnings; is not appropriate.

[reply]
[d/l]
[select]