Juerd wrote:
Larry Wall skribis 2005-03-12 12:26 (-0800):I'll hazard that your mind works that way because in both examples, you're considering the invocant as an indirect object, not a direct object.
And arguably, the current structure of join is that the delimiter is
the invocant, so cat should be defined as ''.join(@foo)
This is what Python does. It does not make any sense to me, and I can't wrap my mind around it at all. Ruby-ish @foo.join('') seems more natural.
Just like with how I prefer $fh.print($text) to $text.print($fh), I
cannot explain WHY this is how my mind works.
Deliver the bucket to the shed.
Makes a lot more sense as:
$bucket.deliver($shed);
Than
$shed.deliver($bucket);
I think that the direct object needs to be the invocant, and the indirect object be the parameter to the method.
However, one could easily say:
Send the String to this File. Augment this File with the String. Shove commas between everything in the list. Give me a list with commas as delimiters.
Which means I think we need all of:
$str.print($fh);
$fh.print($str);
','.join(@list);
@list.join('');I see the argument for having both of them as the same as having the argument for both
foo() if $cond;
if $cond {foo()};
Sometimes it's the $cond that's important, sometimes it's the foo().
Obviously this can't happen for everything, but for the builtin methods and classes, I don't see a penalty for supporting both forms. Consider:
$str.split($rule); $rule.split($str);
I can see using both of those. But I can't see
$int.split($rule, $str);
as an alias for
$str.split($rule, $int_limit);
because I doubt that the limit will ever be the most important thing about a split operation.
-- Rod Adams
