FAQ
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.

This allows to define object-oriented lexical methods that aren't
necessarily blessed code references.

If nobody has objected to it, I'll push it tuesday evening.

Vincent.

Search Discussions

  • Father Chrysostomos at Dec 6, 2010 at 1:13 am

    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.
    Why the special case for scalar references?

    I would expect ‘$bar = \$_; $foo->$bar’ to do this (which it does currently):
    Can't call method "SCALAR(0x826d70)" on an undefined value at -e line 1.

    If $_ is blessed into a class, then string overloading will kick in:

    $ perl5.10.1 -e 'bless \$_; use overload q\""\=>sub{"aaaa"};$bar = \$_; $foo->$bar'
    Can't call method "aaaa" on an undefined value at -e line 1.

    The &{} overloading sounds fine to me, as it’s a bug fix as far as I’m concerned.
  • Vincent Pit at Dec 7, 2010 at 11:55 pm

    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.
  • Zsbán Ambrus at Dec 8, 2010 at 9:48 am

    On Wed, Dec 8, 2010 at 12:59 AM, Vincent Pit wrote:
    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).
    It has three modes in fact: code reference, unqualified method name as
    string, and qualified name (which is looked up using inheritence
    starting from the package name in the string, with the package of the
    object ignored).

    perl -we '{ package X; @X::ISA = "Y"; } { package Y; sub japh { print
    { $_[0] } "Judt another Perl hacker\n"; } } $m = "X::japh";
    STDOUT->$m;'
    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.
    You can also use the third mode to have local methods, so this does
    not alone prove that the code reference is a big win.

    Ambrus
  • Aristotle Pagaltzis at Dec 11, 2010 at 2:53 pm

    * Zsbán Ambrus [2010-12-08 10:50]:
    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.
    You can also use the third mode to have local methods, so this
    does not alone prove that the code reference is a big win.
    You can use `$foo->X::bar` instead of `$foo->$coderef` as well.
    By your logic the latter is not a big win. I will argue that you
    are mistaken.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Zefram at Dec 11, 2010 at 4:13 pm

    Aristotle Pagaltzis wrote:
    You can use `$foo->X::bar` instead of `$foo->$coderef` as well.
    By your logic the latter is not a big win.
    It is possible, and reasonable, to have large numbers of code refs
    that do not have individual package-based names. On the other hand, a
    package-based sub name can always be dereferenced to get the corresponding
    code ref. This is not a symmetric comparison.

    -zefram
  • David Golden at Dec 8, 2010 at 12:56 pm

    On Tue, Dec 7, 2010 at 6:59 PM, Vincent Pit wrote:
    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.
    When both overloadings are present, that's an arbitrary choice of
    order. I would agree with coderef first as the "natural" ordering,
    but I think it should still issue a warning about "ambiguous coderef
    and string overloading resolved as coderef".

    -- David
  • Dr.Ruud at Dec 6, 2010 at 7:57 pm

    On 2010-12-05 20:15, 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.

    This allows to define object-oriented lexical methods that aren't
    necessarily blessed code references.
    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.

    --
    Ruud
  • Zsbán Ambrus at Dec 7, 2010 at 6:47 pm

    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.

    Ambrus
  • Aristotle Pagaltzis at Dec 11, 2010 at 2:48 pm

    * 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?

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedDec 5, '10 at 7:12p
activeDec 11, '10 at 4:13p
posts10
users7
websiteperl.org

People

Translate

site design / logo © 2022 Grokbase