...do you always know when exactly when everything gets declared?

Generally, yes. The use inevitably appears lexically before, and by general definition is compiled before, any statements that call methods that the used module contains.

There are situations, particularly when using require in a thread to avoid cloning, where the loading of the module is deferred, but that is a situation that requires other special considerations--like the explicit invocation of export()--that one has to be aware of.

How about in programs that use Module::Pluggable or another extension mechanism?

I've never had occasion to use that module or anything similar, but looking at the POD it seems that you would always need to obtain a 'handle' to the module first, and using direct method invocation on objects and handles is the natural way to go. There is no bare-word upon which to invoke a class method indirectly.

(I've also debugged the $_ gets localized implicitly except when it doesn't.)

Kind of a strange aside given the subject matter, but useful. Given that this problem is far more subtle, and unlikely to be detected at compile time much less give a clear diagnostic as you get with most incorrectly parsed indirect method invocations, do you generally advocate always explicitly localising $_?

I know there are those that eschew all uses of $_, but I don't recall you as being one of them. It seems to me that when this problem arises, it is far more insidious, far less likely to produce a clear diagnostic and far harder to debug. So why not advocate:

  • "Thou shalt never rely upon implicit localisation of $_?"

    Not that I would subscribe to it, but it seems like a far stronger candidate to me.

    In general, I only use indirect method invocation for class methods, not instance methods.

    Why use it at all? Maybe it's a throwback to my (hated) C++ days. Or maybe it just 'feels right'. I tend to say: "I'm going to by a new car", not "I'm going to by a car new". But mostly I think that applying direct method invocation to a bare-word is unintuitive.

    And the use of contrived examples to deprecate things that work perfectly well in normal situations just seems like bad karma.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    In reply to Re^8: Is it ok to mix functional and oo programming in one package? by BrowserUk
    in thread Is it ok to mix functional and oo programming in one package? by leocharre

    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.