On 8/19/04, [EMAIL PROTECTED] (Larry Wall) wrote:
>It's hard to come up with an English word that means "next" in scalar
>context but "all" in list context.
I never know whether to name my arrays singular or plural, either. =)
But couldn't there be Two Ways To Do It? One "singular" name and one
"plural" that do exactly the same thing -- use whichever one sounds
better in any given context.
>So I lean toward punctuation, and since <> is historical, I like
><$IN> and $IN.<> for that. [...] Arguably .keys, .values, .pairs,
>and .kv should all autoiterate in scalar context, which should
>replace .each entirely. @array should respond to .pairs and .kv,
>pretending the implicit array indexes are hash keys.
Which reminds me that an object can have multiple iterators, that do
different things. (Though there might always be a "default" iterator --
the one that "for" would use.) So that's another reason not to mandate
iterator names at all; <> could still be the socially conventional name
for iterators (or maybe it would only be used by filehandles, depending
on what else we might use <> for).
>It looks like most of the problem is that we're not consistent in
>how to destructively read something in a context sensitive manner.
>And I don't really like .read anyway. Without necessarily
>deprecating .shift or .splice, how about a table that looks like
>this: [.pull's and .value's]
I like the idea of being able to distinguish destructive from non-d.
behaviour when I need to. But a lot of the time I don't care -- I
wouldn't want to have to specify whether I'm pulling or value-ing in
every "for" loop. So we'd still need something like <> (that presumably
defaults to the least destructive iterator available).
- David "does like 'pull' as a good generic name" Green
