I think you are going off in left field.
You asked:
Perhaps we should ask then why logical-only operators ignore undef, bu
+t not why other operators don't ignore it.
I just think of the amount of code out there that is written to av
+oid those warnings.
I think I made this clear earlier. It seems you are trying to change the nature of the discussion or are grasping at straws to prove some unknown point.
You wouldn't turn off warnings for things that compare numbers or magnitude, as it is, inherently an error if you test 'undef' with an operator that compares magnitude. That TRULY, is an indication that you were expecting something that would have relative magnitude to something else, but instead, have something that is completely undefined.
They are completely different. Comparing if two variables have the same value or are both uninitialized, isn't unreasonable. Since 'undef' is often returned for false and a non-zero length string that doesn't eval to 0 is returned for true, someone might simply want to compare the results of two tests to verify that both returned true or both returned false. Sure there are 100's of other ways to do it -- it was just a bit of a poll to see what people used it for and how it was more useful giving warnings as it does now, vs. acting like and/or/not/xor operators.
You really didn't need to go into reasons why you should use
the 'fields' and 'parents' pragma's... they have nothing to do with eq/ne as near as I can tell. I'm not sure what you are getting at in your telling me what is a bug and what is not -- or at least now how that is pertinent to the discussion.
If you can't come up with any good reasons why it should be the way it is, that's fine.
BTW -- IMO, "catching an error", and handling it -- ideally would involve invoking an alternate method to do what you were trying to do -- that's what humans do, unless they give up. Programming computers to continue in spite of errors, is really what is needed in today's SW, since all of it has errors.
The next step in programming, is getting to programs that continue to run and do the right thing in the face of unexpected input -- or at least not to roll over and die.
I have programs that collect status information, and if something is wrong, they take steps to fix it -- progressively, as well as send email at increasing intervals -- up to a day apart as long as the problem continues. More and more, I'm trying to build in redundancy and recovery into my programs, so that they won't harass me for little stuff.
IMO, I tend to believe that the warnings produced for eq and ne aren't worth the problems they turn up, but that may be because I check for errors in others ways (if not in the first pass, eventually, because eventually, I am almost guaranteed to hit every trouble spot!) ;-)
|