Sáb, 2008-06-14 às 09:20 -0700, Larry Wall escreveu:
> On Sat, Jun 14, 2008 at 01:46:10PM +0200, Moritz Lenz wrote:
> : Fallback semantics in S12 suggest that since no matching multi method is
> : found, subs are tried - that is, the expression is interpreted as
> : join('str', 'other_str')
> : yielding 'other_str'. t/spec/S29-list/join.t disagrees, and wants the
> : result to be 'str'.
> I want the result to be 'str'.
Just a sanity check here... Are we really going to change the order of
the parameters of 'join' from p5?
Are we aware that this is going to be a PITA for most p5 developers?
Do we realise that this is only necessary to support
$nonlist.join($separator)
Which, as moritz pointed out on IRC is a very specific corner case,
which only makes sense on something like:
my $a = $cond ?? ( 1 ) !! ( 2, 3, 4 );
$a.join(',');
Which would have the desired effect if used with the proper sigil:
my @a = $cond ?? 1 !! (2,3,4);
@a.join(',');
If we choose to avoid supporting $nonlist.listmethod (which sounds lame
anyway), we can keep the order of parameters in join
join $separator, @list;
join ', ', 1, 2, 3, 4;
Which is considerably saner than:
join 1, 2, 3, 4, ', ';
Moritz convinced me that there's actually no real reason to support
$nonlist.listmethod
And if we stop, and think for more two seconds, we realise that
supporting that could end up having a lot of non-interesting side
effects, because an exported sub with the signature :(Any, Str) is most
likely to have a lot of false hits.
daniel
