Re^6: Sub Return Value Help

But I still don't see why this will be a problem in *all* cases, or in most likelihood the case in question in particular - a single file program which is unlikely to be used in a shared environment: there is no opportunity for any unwanted access to the filehandles.

It should also be borne in mind that whilst the bareword filehandle might be globally accessible, the symbols are package qualified as demonstrated by the following:

use strict;
use warnings;
                                                                      
+          
open FOO, ">x";
                                                                      
+          
package bar;
                                                                      
+          
close FOO or warn "$!\n";;
                                                                      
+          
package main;
                                                                      
+          
print FOO "Gshshsh";
[download]

It would therefore be reasonable to assume the risk of unintentional access is fairly limited, leaving only a notional risk of intentional misuse of the filehandle by some malicious code - and, well, if you are running untrusted code in a manner that would allow that to happen then you have far worse problems than messing with a programs file handles would create.

As I say, lexical filehandles have their uses when it would be tricky or impossible to use bareword filehandles. But I just don't go with the absolutism.

/J\

Comment on Re^6: Sub Return Value Help Download Code

Replies are listed 'Best First'.
Re^7: Sub Return Value Help by JediWizard (Deacon) on Aug 01, 2005 at 23:03 UTC
I just belive in establishing "Best Practices". If it is better for one instance, and has no negative effect in any instance, why not make a habit of always doing it the "best" way? Granted there are a million instances in which a bareword filehandle will not hurt you... But there are as many instances in which putting a gun to your temple and pulling the trigger will not kill you... but that still doesn't mean you should do it. Update: Please enlighten me: when would it be "impossible" to use a lexical scalar over a bareword filehandle? If there is such a situation... I cannot imagine it. They say that time changes things, but you actually have to change them yourself. —Andy Warhol	[reply] [d/l]
Re^8: Sub Return Value Help by gellyfish (Monsignor) on Aug 02, 2005 at 07:57 UTC
You appear to have completely reversed the sense of my last paragraph. I was saying completely the opposite. You are still saying that lexical filehandles are somehow "better" in all cases without providing any concrete reasons. I would agree that lexical filehandles are extremely useful in some circumstances, but I am not buying into this notion that bareword filehandles are somehow "bad practice" just because you have decided to assert this as fact. /J\	[reply]
Re^9: Sub Return Value Help by fishbot_v2 (Chaplain) on Aug 02, 2005 at 13:30 UTC
You appear to have completely reversed the sense of my last paragraph. I was saying completely the opposite. No, I think that it is very simple: you admit that there are cases where bareword filehandles are impossible to use (and you are quite correct). Now, (he asks) are there cases where lexical filehandles are impossible to use, and barewords are preferable? I assert that there are not. Rather than switching back and forth in a dog's breakfast of filehandles, most programmers like to pick the cleanest, most flexible option to standardize on. Now if you change your code in the future from one of those "bareword ok" cases to a "bareword impossible" case, you don't have to alter every reference to the old filehandle. Personally, the winning argument for me is that the scope of a lexical FH is lexically restricted. All things being totally equal, I will pick the option with the narrowest possible scope of effect. I do agree with you that this matter has little to do with the actual question at hand. It is worth mentioning to beginners, though.	[reply]