--- 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