in reply to •Re: Re: Re: OO style: Placement of "new"
in thread OO style: Placement of "new"

Bad things happen in real code all the time, and it's not an argument for the wholesale banishment of certain tools/techniques, but rather a case for better education. In this example, the possible errors are easily obviated by a correct choice of syntax given a very particular set of conditions. If the list parsing is getting munged using indirect invocation, then use direct invocation, or employ parentheses appropriately.

Respectfully, I must say I'm surprised that so many old timers would argue to avoid a feature whose negative consequences are so easily corrected.


"The dead do not recognize context" -- Kai, Lexx
  • Comment on Re: •Re: Re: Re: OO style: Placement of "new"

Replies are listed 'Best First'.
•Re: Re: •Re: Re: Re: OO style: Placement of "new"
by merlyn (Sage) on Apr 08, 2003 at 05:57 UTC
    but rather a case for better education
    The "better education" you are asking for is what we are telling you. "Don't use IO notation - it's broken, at unpredictable times for the lay user".

    The precise definition of when it is broken requires an understanding of the symbol table and things seen so far in the current compilation unit. Since direct-object notation always works, and indirect-object notation is sometimes broken at hard-to-describe times, what's wrong with a wholesale ban?

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

      So the bottom line for this wierd behavior is that modules referenced in indirect method invocations must be compiled before the compilation of the invocation. Given that the vast majority of modules are used this is a problem occurring in fairly rare instances.

      It also seems like a problem that could be fixed with some additional smarts added into the compilation phase. If during compilation new modules are discovered after the BEGIN phase -- as in the example discussed below by dws and tye -- simply make a pass over the compiled code again to correct the misinterpretations. Or simpler, issue a warning in such cases.

      In any case, I've seen indirect notation used successfully in too many tens of thousands of lines of OO Perl to be convinced that it's "a failed experiment".


      "The dead do not recognize context" -- Kai, Lexx
        <Flame-On!>

        It also seems like a problem that could be fixed with some additional smarts added into the compilation phase.

        So, you want the compiler to pick up the slack that you're causing because you want to use a syntactic arrangement that has been deprecated? How falsely Lazy.

        In any case, I've seen indirect notation used successfully in too many tens of thousands of lines of OO Perl to be convinced that it's "a failed experiment".

        Ahh ... the old "I've-never-seen-it-fail-so-it-can't-fail" argument. Reminds me of the recent poll regarding favorite logical fallacies. I think I would've voted for this one. Arguing from personal experience is one of the worst arguments one can make, primarily because it's so seductive and it's almost valid. Even if you have read every single line of Perl code that has ever been written, you still would not be able to conclude that the IO notation is ok to use. It would still be a hypothesis. Maybe, it starts to approach "theory" status, but it's not "Law" status.

        The only way to achieve "Law" status is to mathematically prove that the IO notation will work correctly in all instances. Unfortunately for your attempt, the counter-example has already been demonstrated. Sorry bout your luck!

        "new" is not a keyword. As a method, it cannot use prototypes. The IO notation exists solely as a hack to ease the transition for C++ and Java developers. Larry has said that he wishes the hack had never been approved. Good'nuff for me.

        As for it working in most cases ... to me, that's a testament to the skill of p5p and the flexibility of Perl, not an argument for whether or not the feature isn't a mis-feature.

        <Flame-Off!>

        ------
        We are the carpenters and bricklayers of the Information Age.

        Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

        Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.