in reply to Re^4: Is it ok to mix functional and oo programming in one package?
in thread Is it ok to mix functional and oo programming in one package?

Ahh, interesting. I have never shot myself in the foot with that caliber of bullet. Thank you for elucidating.
  • Comment on Re^5: Is it ok to mix functional and oo programming in one package?

Replies are listed 'Best First'.
Re^6: Is it ok to mix functional and oo programming in one package?
by BrowserUk (Patriarch) on Oct 18, 2007 at 23:20 UTC

    Be aware. If you don't deliberately arrange the code in a weird order, it works just fine. That is, if your modules are loaded before the code that uses them, as in you have use Your::Module;, or even just ensure that the modules are compiled before the code that uses them, then the problem does not arise:

    #!/usr/bin/perl use warnings; use strict; package Foo; sub new { return bless {},shift; } sub hello { print "hello"; } package main; sub new { print "haha"; return; } my $a = new Foo; $a->hello; __END__ C:\test>junk2 hello

    Just another example of the over-zealous promotion of a rare scenario, that by-the-by, provides clear and unambiguous diagnostics, into a "thou shalt not" that throws the baby out with the bath water. Just another justifiction.


    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.
      If you don't deliberately arrange the code in a weird order, it works just fine.

      In larger programs which are not small tests cut down for didactic purposes, do you always know when exactly when everything gets declared? How about in programs that use Module::Pluggable or another extension mechanism?

      I've debugged this problem more than once. (I've also debugged the $_ gets localized implicitly except when it doesn't.) Sure, it's not always a problem... but when it is, it's not always as obvious as anyone would like.

        ...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.
      Ah, but wait, you didn't write
      hello $a;
      Why's that? It works ;-)

        Ah, but wait, you didn't write hello $a;

        True, but when I have an object instance, invoking instance methods using direct method invocation is, well, natural. I'd never think to do it any other way. But class methods on a bare-word...


        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.