Is there a rationale or even benefit behind this syntax, or is it just syntactic sugar for the $obj->some_method notation?

_________
broquaint

Abigail

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.

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

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

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.

For example, calling a method new in indirect notation--as C++ programmers are so wont to do--can be miscompiled into a subroutine call if there's already a new function in scope.

Here's a starting point. Can someone morph this into something that fails?

package Foo;

sub new {
    print "Foo\n";
    bless {}
}

package Bar;

sub new {
    print "Bar\n";
    bless {}
}

sub addFoo {
    my $self = shift;
    $self->{Foo} = new Foo();  # which new gets invoked?
}

package main;

my $bar = new Bar();
$bar->addFoo();  # if there's a bug, this should tickle it
[download]

Perl tries to detect indirect object syntax using sometimes subtle hints. I was able to break your example easily on the first try:

 > perl indobj.pl
Bar
Undefined subroutine &Bar::Foo called at indobj.pl line 10.
[download]

What did I do? I simply moved package Foo to be after package Bar. That way Perl doesn't know that Foo is a package name when it compiles the line of code containing new Foo().
                - tye
Read more... (540 Bytes)

I simply moved package Foo to be after package Bar. That way Perl doesn't know that Foo is a package name ...

So as long as Perl knows that the target is package name (i.e., if you've gotten your uses and requires right, and haven't made a typo in the name), everything works as expected. Otherwise, you have a slightly harder time debugging. Is that about it?

Thanks, broquaint and Abigail-II. The arguments in perlobj are definitely convincing.

After reading tye's post, I think I'll not only continue to use #1, but also switch to HANDLE->print etc. in future.

Which is true for case #1 also. There is nothing special about new, it's only by convention that we use it. Your constructor method can be named anything (literally, "anything"). It's just the wrath of downstream programmers that prevent you from doing so.

And I prefer case #1 for all the reasons all ready pointed out about indirect invocation.

-derby

    my $object = new Thingy;
    print $log "It works!\n" if $object->is_valid();
[download]

    my $object = Thingy->new;
    if ($obj->is_valid()) {
        $log->print("It works!\n");
    }
[download]

This is not completely indirect object syntax:

print $log "It works!\n" if $object->is_valid();

You would instead write:

print $log "It works!\n" if is_valid $object;

Your second snippet would likewise be:

$log->print( "It works!\n" ) if $obj->is_valid();

I fail to see how that is less appealing.

Update: Somebody actually ran into problems using the indirect syntax. See Perl modules and "new".