lists in string context
Juerd
'bar') back then, though. This behaviour I couldn't find in the
Synopses, but it wouldn't be the first time I completely overlook
important information while looking for it.
I think having it stringify as "foobar" is more useful, because in my
scripts I more often join on '' than on ' '. For short join(' ') syntax,
we already have "@array[]". Huffman's principle agrees, for the scope of
my repositories.
With this, I wonder what reverse(LIST) does in scalar context. Does it
join on '', like Perl 5 does? Or on ' ', consistent with current design
for ~LIST?
My gut prefers that both scalar reverse LIST and ~LIST join LIST on ''.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Juerd
> My gut prefers that both scalar reverse LIST and ~LIST join LIST on ''.
scalar reverse LIST probably returns an arrayref.
I meant ~reverse LIST, which should probably do ~LIST at some point
instead of join($sep, LIST), for consistency, and my request is that ~
join on '', not ' '.
Juerd
> Well, we thrashed that one around a lot at one of our meetings, and
> the general consensus was that array interpolation and the default
> stringification of arrays should probably work the same for consistency.
> (Likewise for hashes.) And that the default for both of those needs
> some whitespace.
Fair enough, but does this mean that ~reverse(<foo bar>) eq "rab oof",
and not "raboof"?
> cat(@foo)
> @foo.cat
I like this.
> 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.
Larry Wall
: Juerd skribis 2005-03-12 20:32 (+0100):
: > My gut prefers that both scalar reverse LIST and ~LIST join LIST on ''.
:
: scalar reverse LIST probably returns an arrayref.
:
: I meant ~reverse LIST, which should probably do ~LIST at some point
: instead of join($sep, LIST), for consistency, and my request is that ~
: join on '', not ' '.
Well, we thrashed that one around a lot at one of our meetings, and
the general consensus was that array interpolation and the default
stringification of arrays should probably work the same for consistency.
(Likewise for hashes.) And that the default for both of those needs
some whitespace. Basically we didn't want to have to explain why
print "@foo[]"
is different from
print "{@foo}"
On the other hand, without an argument, the method form of .join:
print "{@foo.join}"
is likely to join on ''. Or you could write
print "@foo.join()"
Or if we decide that's too likely to lead people to write something
confusing like
join(@foo)
then we can come up with some other means of doing it succinctly, such as:
cat(@foo)
@foo.cat
Or we could redefine the signature of join to make the delimiter a
named optional parameter so that join(LIST) assumes a delimiter of ''.
That might raise a few eyebrows though. And arguably, the current
structure of join is that the delimiter is the invocant, so cat
should be defined as
''.join(@foo)
Larry
Rod Adams
>Larry Wall skribis 2005-03-12 12:26 (-0800):
>
>
>>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.
>
>
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.
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
Larry Wall
: Obviously this can't happen for everything, but for the builtin methods
:
: $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.
Just for the record, let me say that I expect the limit parameter
to split to be +$limit and not ?$limit. I think a number of seldom-used
options will go this route. Another consideration is whether the
parameter needs to be considered for MMD.
Larry
Juerd
> Just for the record, let me say that I expect the limit parameter
> to split to be +$limit and not ?$limit. I think a number of seldom-used
> options will go this route. Another consideration is whether the
> parameter needs to be considered for MMD.
Seldom used? Where does this statistic come from?
This said, I don't mind the change, but I will probably be typing
:limit(...) a lot if this does change.
David Storrs
> Larry Wall skribis 2005-03-12 12:26 (-0800):
> > 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.
I'm with you. In my opinion, it is weird to call a method against a
constant value; values aren't supposed to do things, they are supposed
to have things done to /them/. For similar reasons, it is only
slightly less weird to call a method on a variable when that variable
is simply a container for a constant value.
A variable that contains an object or "interface element" (e.g. a
filehandle), I can understand calling methods against that.
Ob flame retardant: I'm not saying that my opinion is necessarily
right, or the other way isn't valid. Just offering a thought on why
Juerd might have this feeling.
--Dks