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