develooper Front page | perl.perl5.porters | Postings from December 2010

Re: Make $obj->$method honours "&{}" overloading on $method

Thread Previous | Thread Next
Aristotle Pagaltzis
December 11, 2010 06:48
Re: Make $obj->$method honours "&{}" overloading on $method
Message ID:
* Zsbán Ambrus <> [2010-12-07 19:50]:
> On Sun, Dec 5, 2010 at 8:15 PM, Vincent Pit <> wrote:
> > The attached patch makes "Package->$method" and
> > "$obj->$method" call "&{}" overloading on $method whenever
> > present. In that case, it is equivalent to "Package->$ret"
> > and "$obj->$ret", where $ret is the value returned from the
> > overloading callback ; except when $ret is a scalar
> > reference, in which case $$ret is used as the method name.
> I don't support this.  When $method is an object, it could mean
> either an indirect named method call or a fake method call
> using a coderef. Perl assumes you mean a named method call so
> it calls the overloaded stringification, eg.
> $ perl -we '{ package X; use overload q/""/ => "str"; sub str
> { "say" } } use IO::Handle; my $m = bless [], "X";
> STDOUT->$m("Just another Perl hacker,")' Just another Perl
> hacker,
> I think this is the right behaviour and it shouldn't be
> changed. We can't have perl check both the string overloading
> and the coderef overloading. The string overloading is the one
> we should check because indirect named method calls are an
> important feature whereas the calling a coderef this way is
> extra.  Thus, I vote on don't apply.

Why not? If $method is a plain string, it yields a normal lookup
for that method. If $method is a plain coderef, that coderef gets
called immediately with the invocant as its first argument. If
$method is an overloaded object, why should it only be able to
emulate the first case, but not the second?

Aristotle Pagaltzis // <>

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About