Larry Wall writes: > next D next N all D all N > ====== ====== ===== ===== > $iter $iter.read ?1 $iter.read ?2 > @array @array.shift @array.for @array.splice @array > $array $array.shift $array.for $array.splice @$array > %hash ?3 %hash.values ?4 %hash.values > $hash ?3 $hash.values ?4 $hash.values > > Hmm. Ignore ?1 and ?2, since it's not clear that iterators can be > read non-destructively. > > 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: > > next D next N all D all N > ====== ====== ===== ===== > $iter $iter.pull ?1 $iter.pull ?2 > @array @array.pull @array.values @array.pull @array > $array $array.pull $array.values $array.pull @$array > %hash %hash.pull %hash.values @array.pull %hash.values > $hash $hash.pull $hash.values @array.pull $hash.values > > After all, a pull is the other end of a push.
That is very tickley. But there's another kind of dissonance there. @array.pull needs to take arguments[1] when called with list pull, otherwise it's basically useless. The same goes for %hash.pull, except I'm not sure what those arguments would be. And I assume that %hash.pull would pull off values, to remain consistent as sortof an array with nonnumeric keys (and no inherint ordering?). Or would it pull off kv pairs, obsoleting the .kv method? It's tempting to do it this way due to the parallelism argument, but it's also tempting to have different names for each, since they all have their various quirks or shades. > Larry [1] And there's a-whole-nother beast in @array.pull arguments, dealing with the issue that I've been wanting to address of @array representing an ordered but not indexed list.
