On Thu, Aug 19, 2004 at 01:54:39PM -0600, Luke Palmer wrote:
: 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.
It's not useless if you just want to interpolate an entire array
destructively. But you can have an arguments to pull that say things
like how many values to pull out. That's assuming Perl doesn't just
up and figure out that
($a,$b,$c) = @array.pull;
really means
($a,$b,$c) = @array.pull(3);
: The same goes for %hash.pull, except I'm not sure what those
: arguments would be.
A pull of n arguments would be pretty useless if you don't know
an ordering. So maybe there's an interaction with sorting somehow.
But then you might as well sort it, put it into a temp array, and
pull from the sorted array, unless you're willing to hide an array
state somewhere in %foo.sort.pull(3). But I think the closest I
want to get to that is the implicit list passed by a pipe operator.
Suppose we named that @=. We might have
%hash.sort ==> do {
while @= {
say @=.pull(5);
}
}
: And I assume that %hash.pull would pull off values, to remain
: consistent as sortof an array with nonnumeric keys (and no inherint
: ordering?).
If it's going to pull destructively, I'd say it wants to pull a pair,
to avoid losing info.
: Or would it pull off kv pairs, obsoleting the .kv method?
But it wouldn't obsolete .kv anyway, since .kv is non-destructive.
: 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.
Yes, that's essentially the anti-perfect-language argument, which is
a very good argument indeed. One must strike a balance on that subject,
and other people will certainly disagree.
Larry
