Re: Autoboxing ... "Yes We Can" ( or how I learned to love TIMTOWTDI )

Genial!

One of the interesting features might be that chains of functions like grep could be read left to right, not right to left. The arrow does not work on lists nor arrays (it imposes scalar context, so it operates on the last member or size, respectively):

#!/usr/bin/perl
use warnings;
use strict;

my $join = sub {join pop, @{shift()} };
my $grep = sub { my $f = pop; [ grep {$f->($_)} @{shift()} ]};
my $say  = sub { print @_, "\n" };

[1 .. 120]->$grep(sub { /0/ } )
          ->$grep(sub { /1/ } )
          ->$join("\n")
          ->$say("\nIt works!");
[download]

You can also define a grep-like "method" of a regex or code ref, or make the function decide based on the type of the argument:

#!/usr/bin/perl
use warnings;
use strict;
use feature qw{ say };


my $grep = sub {
    my $f = shift;
    return { CODE   => sub { grep $f->($_), @_ },
             Regexp => sub { grep /$f/,     @_ },
             q()    => sub { grep $_ <= $f, @_ },
           }->{ref $f}->(@_);
};

say for qr/[01]/->$grep(1 .. 100);
say '-' x 20;
say for sub { not $_ % 10 }->$grep(1 .. 100);
say '-' x 20;
say for 5->$grep(1 .. 100);
[download]

لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

Comment on Re: Autoboxing ... "Yes We Can" ( or how I learned to love TIMTOWTDI ) Select or Download Code

Replies are listed 'Best First'.
Re^2: Autoboxing ... "Yes We Can" ( or how I learned to love TIMTOWTDI ) by LanX (Saint) on Dec 13, 2013 at 21:30 UTC
> The arrow does not work on lists nor arrays (it imposes scalar context, so it operates on the last member or size, respectively): Sadly yes, thats one advantage of autobox, were (IIRC¹) one needs to overload arrow to achieve this. OTOH it's far faster then a normal method call, there is no inheritance chain look-up at run time. Another important difference is that a method "pollutes" the variable namespace, i.e. variables called '$grep' could cause conflicts. Also importing lexical variables from packages won't be easy ( while I can imagine an `eval` -hack in importer). So importing such methods could lead to package vars. But "Pro" or "Con" depends on the perspective. If the intention is to port an OO language like JS or Ruby and to reflect syntax and semantic this should be a cool approach, since most of those languages have no separate namesspaces (no sigils!) Another use case is to have local ad-hoc wrapper methods for objects w/o manipulating corresponding classes. Cheers Rolf ( addicted to the Perl Programming Language) Update ¹) at least thats what I figured out the last time I looked into it, but my Perl foo was limited back then..	[reply] [d/l]
Re^2: Autoboxing ... "Yes We Can" ( or how I learned to love TIMTOWTDI ) by LanX (Saint) on Dec 13, 2013 at 22:53 UTC
`The arrow does not work on lists nor arrays (it imposes scalar context +, so it operates on the last member or size, respectively):` [download] Deeper meditation ...=) Non-scalars are usually simple variables, so the normal function-call syntax can be comfortably applied, for the nested cases you can use the method syntax: `DB<134> sub multi (\@) { print "@{$_[0]}" } DB<135> $multi=\&multi => sub { "???" } DB<136> @array=1..5 => (1, 2, 3, 4, 5) DB<137> multi @array 1 2 3 4 5 DB<141> (\@array)->$multi() 1 2 3 4 5 DB<138> $h[0][1][2]=\@array => [1, 2, 3, 4, 5] DB<139> $h[0][1][2]->$multi() 1 2 3 4 5` [download] I can think of cases were this flexibility of interface comes handy. Cheers Rolf ( addicted to the Perl Programming Language)	[reply] [d/l] [select]

Update