select! not present but reject! is

Discussion in 'Ruby' started by Geert Fannes, Oct 5, 2005.

  1. Geert Fannes

    Geert Fannes Guest

    Content-Type: text/plain;
    Content-Transfer-Encoding: quoted-printable

    Hello, is there a reason why I can find the in-place mutator method
    Array#reject! and not Array#select! ? It is ofcourse easy to add this
    method but it is my feeling this should be added to the core.



    Geert Fannes, Oct 5, 2005
    1. Advertisements

  2. Geert Fannes

    Gene Tani Guest

    Can you use Enumerable#partition ?
    Gene Tani, Oct 5, 2005
    1. Advertisements

  3. Geert Fannes

    Jacob Fugal Guest

    That's beside the point, for two reasons:

    1) Geert's question is regarding the lack of symmetry between the
    presence of Array#reject! but absence of Array#select!.[1]

    2) Geert is interested in in-place mutators (Array#reject!,
    Array#select!). Enumerable#partition returns two new Arrays; it is not
    an in-place mutator.

    As far as work-arounds, this would probably be closest:

    class Array
    def select!
    self.reject! { |e| not yield e }

    But I'm sure Geert is already aware of this (or a better version).
    Geert's question, to which I would like an answer as well, is this:

    Is there a reason Array#select! doesn't exist in the core?

    Jacob Fugal
    Jacob Fugal, Oct 5, 2005
  4. Hi --

    It seems like a strange concept to me. I don't associate
    destructiveness with selecting. I guess there would also be find_all!
    which seems even stranger :)

    I know one *can* implement it (i.e., I'm not saying I don't know what
    it means). I just don't think that in-place removal of items follows
    naturally as a ! version of selecting.

    David A. Black, Oct 5, 2005
  5. Geert Fannes

    Jacob Fugal Guest

    Well, maybe select! isn't the right name for it. But as a concept,
    including the converse of reject! in the core would make sense, at
    least to me. Maybe with a name like Array#keep!, telling ruby which
    elements you want to keep and discarding the rest.

    Jacob Fugal
    Jacob Fugal, Oct 6, 2005
  6. Hi,

    In message "Re: select! not present but reject! is"

    |> Is there a reason Array#select! doesn't exist in the core?
    |It seems like a strange concept to me. I don't associate
    |destructiveness with selecting. I guess there would also be find_all!
    |which seems even stranger :)

    That is a reason. For the same reason, we didn't implement map!, but
    certain number of native speakers persuade me it was not unnatural.
    Now we have map! in Array class. Same thing could happen on select!.

    Yukihiro Matsumoto, Oct 6, 2005
  7. Geert Fannes

    Rob Rypka Guest

    Rob Rypka, Oct 7, 2005
  8. Hi --

    I'm still not feeling a "dangerous version of select". It seems such
    a benign operation :)
    It's a synonym for select; they call the same method. That's a pretty
    hard relationship to disregard :)
    In the middle of writing this I finally got a handle on what bothers
    me about select! as (I think) it's being discussed: it's backwards.

    If you select! elements from an array (dangerous/destructive select),
    those elements should be *removed* from the array. It's like
    selecting people from the audience to come onto the stage: they are
    removed from the audience. The audience is not reduced to being just

    At the same time, the return value of select! should be an array of
    the selected items. The ! part would mean: they've been *permanently
    selected* (withdrawn from the array).

    Here's a whole little testbed for this. In this form it would make
    some sense, though I'm still not happy about the find_all! thing....

    class Array
    def select!
    yes,no = partition {|e| yield(e) }

    a = [1,2,3,4]
    b = a.reject! {|e| e > 2 }
    p a
    p b

    a = [1,2,3,4]
    b =! {|e| e > 2 }
    p a
    p b

    # Output:
    [1, 2]
    [1, 2]
    [1, 2]
    [3, 4]

    David A. Black, Oct 7, 2005
  9. Geert Fannes

    Jacob Fugal Guest

    Hmm, I'd disagree. After all, we're sending the message to the array
    aren't we? I look at it like John the Innocent Array has five apples,
    two shiny and three dull. I come along, as the wise programmer, and
    say to Johnny, "Johnny, shiny apples are good. You only need to keep
    those ones." In Ruby:

    johnny =3D []
    2.times { johnny << }
    3.times { johnny << }

    # ... later ...! { |a| a.shiny? }

    An alternate way to tell this to Johnny would be, "Johnny, shiny
    apples are good. You should get rid of any others." In Ruby:

    johnny.reject! { |a| not a.shiny? }

    However, negating the positive condition (a.shiny?) isn't very
    readable. Syntactically, it is really as easy as "not ( condition )",
    but if condition is long, it may be confusing to try and keep track of
    the ands/ors in condition and then mentally negate it all. Not to
    mention that reject! { not } is a double negative, and we all know how
    bad those can be (/me temporarily flashes back to second grade...
    shudder). Or we can apply DeMorgan's to try and get rid of the not,
    but that often muddles the semantics of the condition.

    In short, select! is just the converse of reject!, and there's no good
    reason not to include it under that context.

    Jacob Fugal
    Jacob Fugal, Oct 7, 2005
  10. Hi --

    That's true across the board, though; it's not a determinant of what
    happens when we send a message.
    Or you could look at it as: "Give me (permanently) all your shiny

    my_apples =! {|a| a.shiny? }

    So now my_apples has them, and johnny doesn't. Mind you, I'm not
    eager to see my version in the language either. I don't like the bang
    method not returning the receiver. But I don't like the semantics, in
    this case, when it does. (And the find_all! thing is a further sign
    that this method was not meant to have a bang version.)

    I think there's been talk in the past of delete_unless. delete_if is
    not quite the same as reject! (one of them returns nil if nothing's
    found; the other returns an array, I believe).

    David A. Black, Oct 7, 2005
  11. Geert Fannes

    Rob Rypka Guest

    But the exclamation mark (to me) says, "Do this to yourself, Mr.
    Array." When you tell the array to reject!, it throws away the
    matches and says, "Here's my state now, what next?" or "Whoops, I
    didn't do anything." I think the same should be applicable for
    Well, I think we should have a Array#gimme and Array#gimme! to
    differentiate from select!. Then you would have your functionality,
    while select! would say (as I think it should), "select these

    By your logic, reject! is also wrong. johnny.reject! should reject
    the items, and then give them to you, which is the same as your
    select!. That's not what it does, though...

    Regarding find_all!, Just because they're synonyms, doesn't mean they
    have to both have the !. If everyone instantly associates select and
    find_all together because they're synonyms, why have them both? I
    don't think they do. People see 'find' and they think, "But I want to
    find everything, not just one," and then they come upon find_all.=20
    With select and reject, it says, "pick these," and "pick everything
    but these." Just because they end up meaning the same thing, doesn't
    mean they have the same connotations.

    find and find_all are the benign operations. select and reject are more ri=
    I believe you are correct (about reject! and delete_if, I don't know
    about the others).

    In all honesty, I don't care what it's called, but reject! feels like
    it should have an opposite.
    Rob Rypka, Oct 7, 2005
  12. I vote for Array#winnow
    Wilson Bilkovich, Oct 7, 2005
  13. Hi --

    See my previous post -- it shows the difference (between reject! and
    my sense of select!), which is in the return values.
    Similarly (in case it's unclear), I have no underlying objection to
    the idea of a reject! opposite :)

    David A. Black, Oct 7, 2005
  14. Geert Fannes

    Jacob Fugal Guest

    And that's where it confuses me. select and reject are complements, so
    why couldn't it be expected that select! and reject! be complements as
    well? Changing the semantics of select from converse of reject without
    bang to synonym for reject (differing only in return value) with bang
    makes no sense at all to me.
    At least we're all agreed on that. :)

    I just fail to see why select should lose it's complementary
    relationship with reject when a bang is added. I suggest we retain
    that relationship and let select! and reject! remain complementary.
    With select and reject we have the following tautology[1]:

    def test(ary)
    selected =3D { |e| yield e }
    rejected =3D ary.reject { |e| yield e }
    rebuilt =3D selected + rejected
    (rebuilt - ary).empty? and (ary - rebuilt).empty?

    I propose select! and reject! should have a similar tautology:

    def test(ary)
    selected =3D! { |e| yield e }
    rejected =3D ary.dup.reject! { |e| yield e }
    rebuilt =3D selected + rejected
    (rebuilt - ary).empty? and (ary - rebuilt).empty?

    Jacob Fugal
    Jacob Fugal, Oct 7, 2005
  15. Hi --

    I completely understand, and I'm the first to admit I've failed to
    convey clearly what it is that makes me not feel that the
    complementariness carries over to the bang versions, or why I like
    "select" for culling elements that pass a test but don't like
    "select!" for replacing the array's contents with elements that pass a
    test. So I'll have to leave it at that, except that if a brilliant
    explanatory model comes to me I'll share it :)

    David A. Black, Oct 7, 2005
  16. Geert Fannes

    Mark Hubbart Guest

    The english words "select" and "reject" are not opposites. "reject"
    and "keep" might be, as someone else suggested.

    Going back, say you have a box of apples, some of which are shiny, the
    rest of which are dull. You don't want the dull ones. If you say:

    apple_box.reject! {|apple| apple.dull?} sounds like you want to reject, or throw out, any dull apples,
    leaving only the shiny ones. The opposite would be:

    apple_box.keep! {|apple| apple.shiny?}

    ...because you want to keep only the shiny ones. "keep" implies that
    the rest are not kept, and are thrown out.

    On the other hand, if you said:! {|apple| apple.shiny?}

    It implies that you want to keep both; you remove the selected ones
    from the box, and leave the unselected ones behind.

    Note that your tautology (as written) for select!/reject! works for
    this version also. "select!" would return an array of the values
    removed from the apple_box.

    Also, I'm not really advocating any action here. I'm just suggesting
    that it would be a little weird for "select!" to be the exact opposite
    of "reject!", since the Ruby definitions wouldn't stand up to the
    English ones.

    Mark Hubbart, Oct 7, 2005
  17. Geert Fannes

    Jacob Fugal Guest

    Funny thing is, it was me that suggested 'keep!'. :) But my argument
    isn't that "select" and "reject" are necessarily opposites in English,
    but that the *existing* non-bang versions of "select" and "reject" in
    Ruby *are*.
    The English usage of "select" could imply that, and I think that's
    what bothers David as well. But, again, my goal isn't consistency with
    English (although some of my previous posts in this thread may have
    appeared that way), but rather consistency within Ruby. "select" and
    "reject" are already direct opposites, so in my mind "select!" and
    "reject!" should also be direct opposites.
    Yes, but this is actually incidental and buggy. I'm of the camp which
    prefers any bang method should return either self (for chaining) or
    nil. I wouldn't want select!/reject! to return either the selected or
    rejected elements. Rather, my example should have been:

    def test( ary )
    (selected =3D ary.dup).select! { |e| yield e }
    (rejected =3D ary.dup).reject! { |e| yield e }
    rebuilt =3D selected + rejected
    (rebuilt - ary).empty? and (ary - rebuilt).empty?

    Under David's interpretation of "select!", this function would rarely
    return true, whereas I would expect it to always return true.
    I'll concede that, but IMNSHO consistency between the non-bang and
    bang versions seems more important.

    Jacob Fugal
    Jacob Fugal, Oct 7, 2005
  18. Geert Fannes

    Rob Rypka Guest

    select and reject (without the exclamation marks) are Ruby opposites,
    though. Nobody seems opposed to that.

    If I had two methods, Array#foo and Array#foo!, I would expect the
    definition of foo! to be:

    "Same as Array#foo, but modifies the receiver in place."

    Sometimes, the above leads to another (near) synonym (like delete_if
    and reject!), but the The return value should be the receiver,
    instead of a new array. To me, foo! doesn't mean finding a new
    meaning of the foo operation in a way that would be destructive, it
    means immediacy to the receiver (which in turn implies destruction).=20
    "Select these elements, but alter your contents and return yourself,
    instead of someone new."

    Anyways, there seems to be enough opposition to select! that Matz
    probably isn't going to add it. I give up the fight (even though I
    still believe I'm right). I'm going to have to learn to live with
    reject!ion (but not select!ion).

    Aside: I second the vote for Array#winnow :)
    Rob Rypka, Oct 7, 2005
  19. Geert Fannes

    Rob Rypka Guest

    Jacob and others are free to continue the fight in my pseudo-absense :)
    Rob Rypka, Oct 7, 2005
  20. The most important thing, though, is that every method name be
    appropriate. If select! ("dangerous select") is the best way to
    communicate the "delete unless..." process, then it's right. If not,
    then not. It's reasonable to expect that a/b == a!/b! -- but the
    existence of a, b, and a! doesn't mean that b! is a good method name
    for the inverse of a!.

    David A. Black, Oct 7, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.