note
Apero
<p>
I'll offer another linguistic interpretation for you and call this <i>heuristically ambiguous</i> object syntax (in addition to Perldoc's own references to <i>indirect</i> as well.)
</p>
<p>
The reason for this is spelled out in the <c>perlobj</c> documentation, which recommends the so-called <i>indirect object</i> syntax be avoided.
</p>
<p>
Consider the code below, which provides both a <c>new</c> and <c>connect</c> constructor.
</p>
<p>
The instantiation of <c>$obj4</c> breaks because <c>connect</c> is also a built-in command, and Perl's heuristics prefer it over the <c>connect</c> constructor of the <c>Example</c> class. The same is true for the popular <c>DBI->connect()</c> constructor, as well as many other real-world examples you find in the wild.
</p>
<p>
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 ;).
</p>
<readmore>
<c>
use strict;
use warnings;
my $obj1 = Example->new();
my $obj2 = new Example;
my $obj3 = Example->connect();
my $obj4 = connect Example;
package Example;
# Constructors
# (be subclass friendly, even in example code ;)
sub new {
my $class = shift;
$class = ref($class) || $class; # subclass boilerplate.
return bless { }, $class;
}
sub connect {
my $class = shift;
$class = ref($class) || $class; # subclass boilerplate.
return bless { }, $class;
}
</c>
</readmore>
1148361
1148361