Re^7: magic-diamond <> behavior -- WHAT?! (dock)
by Fletch (Bishop) on Oct 31, 2008 at 17:32 UTC
|
The equivalent code shows using what appears to me to be Perl's two-arg open. It's open(ARGV, $ARGV), and (consulting my fingers to double check) that seems to be, erm, two arguments. Yet you say you expect that particular one use of two-arg open to not be magical for just what reason?
If that were not the case then I'd expect an explicit notation that the normal two-arg open magicalness wasn't enabled since that would be different from the normal behavior of two-arg open anywhere else. As no expectation was given to the contrary, being shown that "This works like this snippet in which there's a two-arg open" leads to the reasonable expectation that filenames passed through this construct will behave just like filenames passed to two-arg open. Again, it's doing just what the diagram on the tin shows.
The same equivalent-for-<> code's been used back at least as far as the fourteen year old 4.0.36 manpage (back when all there was was two-arg open and you had to carry globrefs uphill both ways in the snow . . .) showing calling two-arg open identical to the code from the 2nd edition camel already shown.
To expect <>'s file opening not to behave as two-arg open and claim it's not documented as doing so doesn't match up.
And again: while I agree it would sane and safer to change the default, I can see why the no-backwards-compatibility-breaking-changes p5p decision was against removing 14+-year-old documented behavior.
At any rate we're way off into #386 territory here so . . .
The cake is a lie.
The cake is a lie.
The cake is a lie.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
It is "Perl-like" and "pseudo code". You appear to have a great deal of faith in the effort and precision that was put into that smidge of "code" especially given the multiple layers of weasel words that were applied to it.
Yes, I find it completely reasonable to jump from "Perl-like pseudo code" to "a very simple 'open' should not just be assumed to be more than just a pseudo-code 'open' that looks rather Perl-like and may or may not agree with a verbatum translation into real-Perl real code in any particular subtle aspect". So, if there is a possiblity that a simple <> might run off and do system("rm -rf .."), that would be something worth calling out explicitly.
But, yes, it does hint at the possibility of magicalness in the most coy of ways. But it is also completely trounced in the amount of documentation spread over multiple places that talks about <>, -n, and -p in terms of dealing with filenames in @ARGV and showing lots of examples that clearly expect <> do deal with filenames in @ARGV and not a single example even hinting at the magicalness or any English statement even hinting at the magicalness (and nothing at all hinting at the magicalness beyond the one extra-coy connection can that be drawn after the fact, of course).
To be frank, the lack of calling out of whether or not the "Perl-like pseudo code" 'open' was magical or not is just another demonstration of the lack of realization of this subtlety at the time of implementation and of documentation. It is more suggestive of a lack of attention to this detail which is rather the opposite of the claim "See! Look! It was clearly meant to be this way all along! The documentation is obvious on that point! We must never change it!".
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
Yes, I find it completely reasonable to jump from "Perl-like pseudo code" to "a very simple 'open' should not just be assumed to be more than just a pseudo-code 'open' that looks rather Perl-like and may or may not agree with a verbatum translation into real-Perl real code in any particular subtle aspect".
Considering the explaination mentions a reason why the code isn't quite equivalent, and that reason isn't that the open in the pseudo-code is quite different from Perls open(), and that the authors don't sanitize the filename of special characters, I find it unreasonable to assume the open in the pseudo-code is quite different from Perls open.
"See! Look! It was clearly meant to be this way all along! The documentation is obvious on that point! We must never change it!"
The reason it isn't changed isn't because it's documented, at least, that's not all of it. There's a strong tendency on p5p to not break existing code. Bug fixes can trump that, but the view on p5p is that the current behaviour is as it was intended, and not a bug.
| [reply] [Watch: Dir/Any] |
|
|
|
|
|
The example pseudocode was written before three-argument open existed in Perl. I fail to see how that makes for a binding decision once the recommended non-magic open came along.
I'm not going to get into the middle of the argument at this particular time of whether the behavior should be changed to use three-argument open or stay the way it is. I'm fairly ambivalent about this topic currently, partly because being a lone-wolf coder on smaller projects I have the luxury of knowing the contents of my directories really well. I cared more about the status of this feature when I was handling large numbers of other people's files on a server.
I do expect people who are making strong arguments one way or the other to have strong points, though. This particular line of argument does not appear to me to be a very strong one. If I was defending your position, I'd look for some better points to make than that the old pseudocode in the documentation shows the function that was available at the time the documentation was written.
| [reply] [Watch: Dir/Any] |
|
The original 20+-year old code has no "pseudo-" qualifier. Read it again and please point out where it says anything about that being "pseudocode". I don't know how much clearer it could be, but:
THE ONLY REASON THAT SNIPPET IS CALLED PSEUDOCODE IN THE CURRENT DOCUMENTATION IS THAT IT USES THE NAME ARGV FOR A FILEHANDLE AS IF A FILEHANDLE WITH THE NAME ARGV WERE NOT OTHERWISE MAGIC.
IT IS OTHERWISE THE EXACT SAME FRELLING REAL PERL CODE FROM VERSION 1.0'S MANUAL PAGE, AND WERE YOU TO SIMPLY CHANGE THE NAME OF THE SAMPLE FILEHANDLE FROM ARGV TO FRED IT WOULD WORK THE SAME AS <>.
SAYING THAT MAGIC <> WAS MEANT TO BE NOT MAGICAL BECAUSE OF THAT DISTINCTION IS MISSING THE POINT OF THE QUALIFICATION COMPLETELY.
Two-argument open has always been magic for filenames begining or ending in pipes (which are referred to (and have been referred to as such for, again, 20+-years) as just 'filenames' and not 'sooper magical pipey filenames of justice' or what have you; which means any distinction with regards to two-arg open is a misunderstanding as it is two-arg open which imparts special meaning upon filenames of a specific format). <> is magic. <> has always been magic. If you don't want the magic, you don't use the magical form either back 20+-years ago or with the current versions. But to say that it never was intended to be magic is just ahistorical revisionism, and was pointed out as such during the discussion on p5p.
The cake is a lie.
The cake is a lie.
The cake is a lie.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
A reply falls below the community's threshold of quality. You may see it by logging in.
|