Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

geoff (2013)

geoff
  reversethis-{gro ... om} {ta} {ffoeg}
http://www.modperlcookbook.org/

see http://www.modperlcookbook.org/~geoff/ [modperlcookbook.org] for personal information, links to presentations, GPG key, and so on.

Journal of geoff (2013)

Tuesday August 23, 2005
09:34 AM

method call clarity

[ #26429 ]
ok, so every shop has style guidelines, and some of those style preferences differ from my own, and I'm perfectly fine with that - if the team wants 4 spaces but I'm a two-spacer, or if they don't care that they have some lines that are 172 characters, fine. but this one just doesn't make any sense to me:

all method/function calls end in () for 'clarity'

now, for function calls like this

  my $foo = bar();

I think it makes sense, since the definition of bar() might get shuffled in larger codebases so just using the bareword might fail to compile someday.

for method calls, however, I'm completely unconvinced. I don't see how

  my $foo = $obj->bar;

is any less clear than

  my $foo = $obj->bar();

but perl has lots of little easter eggs that even the best of us don't know, so I ask: in this case can

  $obj->bar

ever mean anything different than

  $obj->bar()

? and I don't mean for cases where you need to pass in arguments :) and I don't mean cases where () is required and tricky, like

  my $foo = $cv->();

I mean, in all seriousness, exactly how does () add clarity to a method call? what else could you possibly expect ->bar to represent?

maybe it's the difference between

  $obj->bar

and

  $obj->{bar}

? if so, I don't buy it :)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Maybe they are taking other languages into consideration. For example, to someone with a PHP background, this looks like a property:

    my $foo = $obj->bar;

    This looks like a method:

    my $foo = $obj->bar();

    I think the parentheses universally indicate a function or method, so that might be what they mean by clarity.

  • Sorry Geoff, I'm in total agreement with this style guideline. I find it much easier to scan the code when the method calls end in (). I find it especially good in cases where they are chained.
    • ugh... it's chaining where I find them the most superfluous
        my $val = Foo->new->attribute->format;
      just feels much more idiomatic to me than
        my $val = Foo->new()->attribute()->format();
      but ok, you're a reasonable guy, so I'll give in :)
      • Imagine a mixed-case like this:

        my $val = Foo->new->{attribute}->format->{id};

        It can get confusing quickly, especially when people do that horrible "return yourself" method chaining that SOAP-Lite uses. I know I'm in the minority on this though. I just don't think there's any advantage to leaving them off, and it makes your code less consistent.
  • A sub is a property is a sub. What about when using the :lvalue attributes; as evil as they are?

    sub value : lvalue {
        my $this = shift;
        $this->{VALUE};
    };

    Would you put the parens here:

    my $value = $self->name();

    but not here:

    $self->name = 'Chris';

    or leave it

    $self->name() = 'Chris';

  • ...make maintainance easier.

    In this case, that may make the code more greppable. So you don't have "->foobar" results when you grep for "->foo" for example. (Note that I and my shop both disagree with this particular guideline :)

  • Is that at least that style item can be automated by perltidy.

    Oh wait, I'm dreaming about the PPI automanipulatification of Perl::Style (or perhaps you'd call it Perl::MyWay)...

    In any case I REALLY need to get around to getting that written. :/