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