Hello muba,

Here’s the official explanation, from perlglossary:

• indirect object
  
  In English grammar, a short noun phrase between a verb and its direct object indicating the beneficiary or recipient of the action. In Perl, print STDOUT "$foo\n"; can be understood as “verb indirect-object object”, where STDOUT is the recipient of the print action, and "$foo" is the object being printed. Similarly, when invoking a method, you might place the invocant in the dative slot between the method and its arguments:

      $gollum = new Pathetic::Creature "Sméagol";
      give $gollum "Fisssssh!";
      give $gollum "Precious!";
  [download]

• indirect object slot
  
  The syntactic position falling between a method call and its arguments when using the indirect object invocation syntax. (The slot is distinguished by the absence of a comma between it and the next argument.) STDERR is in the indirect object slot here:

      print STDERR "Awake! Awake! Fear, Fire, Foes! Awake!\n";
  [download]

So in the case of $cgi = new CGI;, this is actually short for something like:

@args = (); $cgi = new CGI @args;
[download]

Does an expression such as $cgi = new CGI; violate the English rule that an indirect object is not present unless a direct object is also present? Yes, unless the (null) method arguments can be said to be “understood” in this case. (Cf. the sentence “Listen to me!” in which the subject “you” is also said to be “understood.”)

Hope that helps,

In Perl, print STDOUT "$foo\n"; can be understood as "verb indirect-object object", where STDOUT is the recipient of the print action, and "$foo" is the object being printed.

Except that that's wrong. "$foo" is not an object -- direct or otherwise.

Properly,

method $object @args;
[download]

is "indirect object syntax", in Perl lingo, and

$object->method( @args );
[download]

is "direct object syntax". Same object; only the syntax is different. And English grammar terminology doesn't really apply well.

And the fact that @larry decided in their infinite (ly mistaken) "wisdom" to coin a completely unnecessary and superfluous alternative term for object, namely "invocant", manifests their misunderstanding of what an object is, in object-oriented programming. For "invocant" means, quite simply, "caller". But in print $fh or $fh->print, $fh is not the caller, it is the receiver. It is the object, not the subject, of the action.

I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.

Hope that helps,

That explains it perfectly. Thank you!

I doubt anyone was thinking in the accusative / dative pattern.

Though you might read new CGI as calling new from CGI .

I think it's called indirect syntax in contrast to CGI->new being the direct syntax.

/me ponders that...

Possibly.

Though you might read new CGI as calling new from CGI .

This would hold for new SomeClass, mostly because "new" is hardly a verb. It's an adjective, at best. Were new called create (construct, make, whatever) instead, as in $cgi = create CGI then we'd be right back at the kick $ball example. The grammatical object (CGI, SomeClass, $ball, $foo, et cetera) we're dealing with is something that is directly acted upon.

Another example could be save $file, assuming that somehow $file->can('save') . Again, the grammatical object is a direct one.

Contrast that with

move $file "~";  # $file->move("~"), or move a file to one's home dire
+ctory,
                 # where $file is the thing being acted upon *directly
+*
                 # and "~" is just another grammatical argument to the
+ verb.
[download]

I'll offer another linguistic interpretation for you and call this heuristically ambiguous object syntax (in addition to Perldoc's own references to indirect as well.)

The reason for this is spelled out in the perlobj documentation, which recommends the so-called indirect object syntax be avoided.

Consider the code below, which provides both a new and connect constructor.

The instantiation of $obj4 breaks because connect is also a built-in command, and Perl's heuristics prefer it over the connect constructor of the Example class. The same is true for the popular DBI->connect() constructor, as well as many other real-world examples you find in the wild.

It's best not to let something as muddy as heuristics determine what your code does, so I personally avoid such constructs with a passion. Leave that stuff to Java where it belongs ;).

Apero, although I do thank you for chiming in and demonstrating why using the thing called "indirect object syntax" isn't a good idea, my question wasn't about that. I am (almost) fully aware of the drawbacks of the syntax. My question was more about whether —from a linguistical point of view— the name "indirect object" was the most accurate.

Again, I'd like to use the kick $ball; # i.e. $ball->kick example, where $ball obviously is a direct object and not an indirect object.

But Athanasius nicely quoted the friendly manual and made me realize that, although Perl does resemble English, Perl simply isn't English.

My question was more about whether —from a linguistical point of view— the name "indirect object" was the most accurate.

I figured, although backing up my alternative naming convention (which I'll hardly claim as the "best", or even better than indirect) with reasoning might help another reader realize what's going on behind the scenes when making Perl English readable; that's not always a useful metric as you noted.

The discussion is interesting since many of Perl's constructs can be read in an English-like way (even promoted as options at times, as in use English. On the other hand, I frequently find lines, especially long unbroken ones, hard to read.

Some more musing (or rambling, depending on your opinion) on subject/verb ordering in Perl follows..

Read more... (2 kB)

I didn't mean to take away from your linguistic pondering too much (although hopefully another reader can benefit from that.) In any event, thanks for the discussion!