in reply to OO style: Placement of "new"

Don't use syntax 2 (also known as "indirect object method"). For reasons why you shouldn't use it, read the section named Indirect Object Syntax in the perlobj manual page.

Abigail

Replies are listed 'Best First'.
Re: Re: OO style: Placement of "new"
by bart (Canon) on Apr 08, 2003 at 09:41 UTC
    I fail to see any actual prohibition in that section, at least, not on class methods. To be honest, most of what's said in that section doesn't even belong in there. The only warning I actually spot against it there, is on that "parens around all parameters" thing: 
      new Critter ('Bam' x 2), 1.4, 45

    [download]
    However, that's precisely the same problem you get when you do 
    print ('Bam' x 2), 1.4, 45;

    [download]
    so that's nothing new.

    OTOH, the one problem I did notice with this "indirect object method", is that it doesn't work with perl's built-in keywords — and likely other predefined subs as well, so the next doesn't call the method "open" in the class "ReadFile": 

    my $handle = open ReadFile($file);

    [download]
    Instead, you have to use 
    my $handle = ReadFile->open($file);

    [download]
    I guess that falls under "the same ambiguity as ordinary list operators", in perlobj.
[reply]
[d/l]
[select]
      The problem isn't precedence. The problem isn't keywords either. The problem is that 
          new Foo;

      [download]

      might call either of 

          &new ('Foo');   # Calling new in the current package

      [download]

      or 

          Foo -> new ();  # Calling new in Foo, or a parent class

      [download]

      And there are a bunch of cases that decide which one it will be.

      And no, Perl doesn't like "prohibitions". You are free to do whatever you fancy. But the documentation does give advices on how not to get hurt.

      Abigail

[reply]
[d/l]
[select]
Re: Re: OO style: Placement of "new"
by djantzen (Priest) on Apr 08, 2003 at 03:21 UTC

    A blanket prohibition like this is as unwarranted as forbidding the use of $_ on the assertion that it is obfuscation. I use the indirect syntax for constructor calls almost exclusively and I have never encountered the problems described in perlobj.

    crenz, use whatever form suits your tastes or the coding style your project settles upon, and allow the constraints of a particular situation to guide your selection of syntax.

    "The dead do not recognize context" -- Kai, Lexx
[reply]
[d/l]
      Well, maybe you haven't, but that doesn't mean nobody hasn't, because I have. So it happens in real code.

      Don't use IO notation. It was an interesting experiment, but it failed.

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

[reply]

        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
[reply]

In Section Seekers of Perl Wisdom