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