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

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

Thread Previous | Thread Next
From:
Vincent Pit
Date:
December 7, 2010 15:55
Subject:
Re: Make $obj->$method honours "&{}" overloading on $method
Message ID:
4CFECA53.1000106@profvince.com
The 06/12/2010 02:12, Father Chrysostomos wrote :
> Why the special case for scalar references?
Because it was a natural (at the implementation level) side effect of
the change. I was neutral about it, so I just left it as is. But now I
agree that it's cleaner to disable it explicitely, and only allow the
overload callback to return code references.


The 06/12/2010 20:57, Dr.Ruud wrote :
> I can read this in several ways, but maybe I am just wishing to much.
>
> Does this include exhaustive (and memoizable, and lazy) resolution?
> Would be great fun.
>
Sorry, I don't understand what do you expect by this. This change
doesn't add any high level concept. What you use it for is left to your
imagination. :)


The 07/12/2010 19:47, Zsbán Ambrus wrote :
> 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 don't really get what you mean by "indirect named method call", but
whatever. I'm sure you're already aware that the

   $obj->$method(@args)

syntax already has two meanings, depending on whether $method is a code
reference or something else (which then gets stringified, either through
stringification overloading or the usual way). I would expect that
syntax to honour both overloading behaviours that are covered by those
two meanings : code dereference overloading, and then stringification
overloading.

> 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.
Conceptually, calling a code reference that way isn't the "extra" mode,
because it can cover the method name case:

    my $m = sub { shift->say(@_) };
    STDOUT->$m("Just another Perl hacker,");

Also, if you want to define local methods and you can only use method
names, you have to install your methods into the object's class, because
methods are subs and subs are global. The code reference calling mode
allows you to define such local methods but in a lexical way. I still
think it's a big win.


Starting tomorrow, I'll be travelling for work, so I'm postponing this
matter for a few days.


Vincent.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About