From: Quinn Dunkan Date: 2000-04-04T17:01:30-07:00 Subject: [ruby-talk:02359] Re: Function of Array.filter surprises me [ matz ] > |filter also makes sense to anyone who's used any language other than smallta > lk > |that has this function (except perl, of course, which uses 'grep' apparently > |in an attempt to confuse shell programmers). Uh, the non-destructive versio > n, > |I mean (that ruby calles `detect'). > > I think you mean `select' or `find_all'. Oops, uh yeah, that is what I meant :) [ Conrad ] # ??? "this function" WRT Ruby? Then I think the previous but snipped ref to # Perl's map (versus grep here) was correct. Sorry about the convoluted sentence there. You mentioned that filter made sense from a certain obscure unix point of view, and I was making the point that filter (the sane, normal filter, not the ruby meaning :) is the standard term for ruby's select (which already has a meaning to unix people---what other language do we know that has two meanings for `select' :). There's nothing obscure about it: every language I've used that has that function calls it filter, except perl, smalltalk, and now ruby. smalltalk's excuse: been that way since the '80s. perl's excuse: does perl really need an excuse? ruby's excuse: "smalltalk does it" ? # # think collect isn't so bad, and it's certainly not going anywhere. I # would # # also highly discourage convert, transform, or other non-standard # # not-invented-here stuff (smalltalk has a sort of excuse of being old :) # # (Then smalltalk should know better by now :-) Ok, then, *you* try to get smalltalkers to do something any way other than their own way... go talk to squeakers about left-flapping scrollbars :) # Meanwhile, I would like to see *every* mutator method without an !-form have # a standard alias to the corresponding !-form in the mean time. Then even Even though I think ruby already has too many aliases, this makes some sense, but only for methods for which a mutating version would be useful. But then, I don't think ruby's `filter' mutation is useful, so who am I to judge? > I'm not going to change `filter' behavior, so there would not be > `filter!'. But I may declare it deprecated in the future if I find > better name. Ok, then let me suggest: no name :) Is there any place where it wouldn't be an overall improvement to lose it entirely, and replace with `foo = foo.collect {...}' ? I can see the use of sort!, reverse!, and uniq!... maybe I'm just weird :) Ok, then if other people really like it, then I suggest collect! or better, map! (but changing collect to map would probably be a big problem, since that at least is a very useful method). > Agreed. The reason for collect/filter is that I felt > > collect values in place > > is weird, comparing e.g. > > sort elements in place > substitute string in place > > But if you guys feel OK for collect!/map!, I sould seriously consider > renaming `filter'. Then don't think of it as `collect'! Think of it as `apply operation to each element of the list'. Coming from functional land, I think of map / collect as `for loop' (or rather, `for loop' as `map'). Maybe this is just a sign that collect isn't the best name :) Anyway, you could say `collect' = `for loop' and `collect!' = `for loop that modifies the list' and the (purely semantic) weirdness goes away. But I do agree with you that we should avoid semantic weirdness. But consistency always wins, at least for me. > Pass block using █ e.g. Ah, I see now. An iterative approach is probably more idiomatic anyway.