I guess that’s my own idiosyncrasy. To me, it seems odd to use 'defined $var', if what you really want to do is check whether the value of $var is undef. I'd be curious to know how many other monks would think '$var eq undef' is idiosyncratic.

Well, it really depends on what you think "eq" should do, and how it should work. There are benefits to both approaches, I think.

If you think "eq" should compare two strings, then comparing one string against something that is specifically a special value that is *NOT* a string should flag a warning. (Let's assume warnings are always turned on for the purposes of this discussion.)

If you think that "eq" should tell you whether two things are "set the same", then "eq" should "compare silently" to undef(); that is, the comparison should not generate a warning a string is compared to undef. This has the advantage of convenience and simplicity, but it also has a few drawbacks.

In this alternative definition of "eq", to be consistant, you probably want every undefined expression to compare silently equal to every other undefined expression. If you do that, however, you might not catch all the kinds of errors that you may want to catch. For example, the following code will flag a warning under the current meaning of "eq", but wouldn't for the alternative meaning. 

$x = input_line(); # input_line returns undef on failure
$y = input_line(); 
if ( $x eq $y ) {
    # checks to see if both lines are equal  
}

[download]

Of course, you could always make "eq" have a third, more complicated definition: (a) when two strings are compared, "eq" generates warnings if one string is undefined, BUT (b) when one string and the constant "undef" are compared, "eq" will not generate any warnings.

This third definition would probably work, but I'm not convinced it's any simpler than the existing system. Right now, all you have to decide is whether the comparison involves undef, or if it doesn't. The third definition requires that you distinguish between two subtly different "undefined values": the undefined value that comes from an expression vs. the undefined value that comes from a special constant. That sounds like too much work to me!

The current definition of "eq" (and other comparison operators) seems like the simplest tradeoff between convenience, and power that I can think of, so that's why I favour it, despite the initial awkwardness of getting used to using defined() all the time.

In reply to Re^6: Breaking The Rules by Anonymous Monk
in thread Breaking The Rules by Limbic~Region

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.