--- Brent Dax <[EMAIL PROTECTED]> wrote:
> Simon Cozens:
> # [EMAIL PROTECTED] (Brent Dax) writes:
> # > # could do the same thing with a sub with a prototype of
> # > # (&block, *@list).
> # >
> # > Great. That could mean it won't work right for
> # > MyCustomArrayLikeThing.
> #
> # Can you explain what you mean by this, because it's not
> # apparent to me that your statement is in any way correct.
>
> OK. Let's say I'm implementing HugeOnDiskArray, and instead of
> slurping
> the array in and grepping over it, I want to grab the elements one at
> a
> time, run them through the grep function's coderef, and stick them in
> another HugeOnDiskArray. Or, if I have RemoteArray (which works with
> an
> array on another computer via a server and a TCP/IP connection), I
> might
> want to try to serialize the code reference given to grep and run the
> grep on the remote computer. (If I can't serialize the coderef due
> to,
> say, nonsense with closures, I'd run the grep locally.)
>
> No, "it won't work efficiently" isn't the same as "it won't work",
> but I
> suspect there are cases I haven't thought of.
I don't follow your example. If you can make
@safe_text = grep { ! /fnord/; } @HugeArrayOnDisk;
work, then why couldn't you make
@HugeArrayOnDisk -> grep { ! /fnord/; } -> @safe_text;
work just as well? I haven't read anything which says that the
different expressions call different incarnations of grep at the
bottom. (That would be the Array are/aren't Objects thread, and its
result STILL shouldn't impact the behavior of grin.)
=Austin
