select! not present but reject! is

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

  1. Geert Fannes

    Geert Fannes Guest

    ------_=_NextPart_001_01C5C9A3.054922C0
    Content-Type: text/plain;
    charset="US-ASCII"
    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.

    Greetings,

    Geert.


    ------_=_NextPart_001_01C5C9A3.054922C0--
    Geert Fannes, Oct 5, 2005
    #1
    1. Advertising

  2. Geert Fannes

    Gene Tani Guest

    Can you use Enumerable#partition ?

    Geert Fannes wrote:
    > 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.
    >
    > Greetings,
    >
    > Geert.
    Gene Tani, Oct 5, 2005
    #2
    1. Advertising

  3. Geert Fannes

    Jacob Fugal Guest

    On 10/5/05, Gene Tani <> wrote:
    > Can you use Enumerable#partition ?
    >
    > Geert Fannes wrote:
    > > 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.


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

    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
    #3
  4. Hi --

    On Thu, 6 Oct 2005, Jacob Fugal wrote:

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

    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

    --
    David A. Black
    David A. Black, Oct 5, 2005
    #4
  5. Geert Fannes

    Jacob Fugal Guest

    On 10/5/05, David A. Black <> wrote:
    > Hi --
    >
    > On Thu, 6 Oct 2005, Jacob Fugal wrote:
    >
    > > 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 :)
    >
    > 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.


    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
    #5
  6. Hi,

    In message "Re: select! not present but reject! is"
    on Thu, 6 Oct 2005 06:47:35 +0900, "David A. Black" <> writes:

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

    matz.
    Yukihiro Matsumoto, Oct 6, 2005
    #6
  7. Geert Fannes

    Rob Rypka Guest

    On 10/6/05, Yukihiro Matsumoto <> wrote:
    > In message "Re: select! not present but reject! is"
    > on Thu, 6 Oct 2005 06:47:35 +0900, "David A. Black" <dblack@wobblini.=

    net> writes:
    >
    > |> 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 :)


    You don't watch enough reality television. The fun of selecting
    winners on this week's episode is rejecting everyone else. I also
    don't think of reject as non-destructive, but there it is.

    I think the exclamation paradigm overrides the subjective connotation
    of select and reject. Regardless of whether or not someone uses it in
    their own code, I doubt anyone would be confused by the meaning.

    Select and reject are perfect compliments. I have, on several
    occasions, tried to use select!, but had to rewrite them with reject!
    instead (not a difficult transition).

    As for find_all!, that's just hard to read (and hard to distinguish
    from find_all with many fonts), so I would never use it. Then again,
    find_all (regardless of its relationship to select and reject) comes
    off as an extension of find, and the correlating find! method would be
    silly (although fitting with the reality television metaphor).

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


    I'll cast my vote for Array#select!, natively speaking.

    --
    Rob (rambling with large words)
    Rob Rypka, Oct 7, 2005
    #7
  8. Hi --

    On Fri, 7 Oct 2005, Rob Rypka wrote:

    > I think the exclamation paradigm overrides the subjective connotation
    > of select and reject. Regardless of whether or not someone uses it in
    > their own code, I doubt anyone would be confused by the meaning.


    I'm still not feeling a "dangerous version of select". It seems such
    a benign operation :)

    > Select and reject are perfect compliments. I have, on several
    > occasions, tried to use select!, but had to rewrite them with reject!
    > instead (not a difficult transition).
    >
    > As for find_all!, that's just hard to read (and hard to distinguish
    > from find_all with many fonts), so I would never use it. Then again,
    > find_all (regardless of its relationship to select and reject) comes


    It's a synonym for select; they call the same method. That's a pretty
    hard relationship to disregard :)

    > off as an extension of find, and the correlating find! method would be
    > silly (although fitting with the reality television metaphor).


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

    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) }
    replace(no)
    yes
    end
    end

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

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

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


    David

    --
    David A. Black
    David A. Black, Oct 7, 2005
    #8
  9. Geert Fannes

    Jacob Fugal Guest

    On 10/6/05, David A. Black <> wrote:
    > ...
    >
    > 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
    > them.


    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 << ShinyApple.new }
    3.times { johnny << DullApple.new }

    # ... later ...

    johnny.select! { |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
    #9
  10. Hi --

    On Fri, 7 Oct 2005, Jacob Fugal wrote:

    > On 10/6/05, David A. Black <> wrote:
    >> ...
    >>
    >> 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
    >> them.

    >
    > Hmm, I'd disagree. After all, we're sending the message to the array
    > aren't we?


    That's true across the board, though; it's not a determinant of what
    happens when we send a message.

    > 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 = []
    > 2.times { johnny << ShinyApple.new }
    > 3.times { johnny << DullApple.new }
    >
    > # ... later ...
    >
    > johnny.select! { |a| a.shiny? }


    Or you could look at it as: "Give me (permanently) all your shiny
    apples!"

    my_apples = johnny.select! {|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

    --
    David A. Black
    David A. Black, Oct 7, 2005
    #10
  11. Geert Fannes

    Rob Rypka Guest

    On 10/6/05, David A. Black <> wrote:
    > On Fri, 7 Oct 2005, Jacob Fugal wrote:
    > > On 10/6/05, David A. Black <> wrote:
    > >> 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
    > >> them.

    > >
    > > Hmm, I'd disagree. After all, we're sending the message to the array
    > > aren't we?

    >
    > That's true across the board, though; it's not a determinant of what
    > happens when we send a message.


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

    > Or you could look at it as: "Give me (permanently) all your shiny
    > apples!"
    >
    > my_apples =3D johnny.select! {|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.)


    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
    (permanently)."

    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=
    sque.

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


    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 (Pontificating at a Late Hour)
    Rob Rypka, Oct 7, 2005
    #11
  12. On 10/6/05, Rob Rypka <> wrote:
    > On 10/6/05, David A. Black <> wrote:
    > > On Fri, 7 Oct 2005, Jacob Fugal wrote:
    > > > On 10/6/05, David A. Black <> wrote:

    > 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
    > (permanently)."
    >


    I vote for Array#winnow
    Wilson Bilkovich, Oct 7, 2005
    #12
  13. Hi --

    On Fri, 7 Oct 2005, Rob Rypka wrote:

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


    See my previous post -- it shows the difference (between reject! and
    my sense of select!), which is in the return values.

    > In all honesty, I don't care what it's called, but reject! feels like
    > it should have an opposite.


    Similarly (in case it's unclear), I have no underlying objection to
    the idea of a reject! opposite :)


    David

    --
    David A. Black
    David A. Black, Oct 7, 2005
    #13
  14. Geert Fannes

    Jacob Fugal Guest

    On 10/7/05, David A. Black <> wrote:
    > Hi --
    >
    > On Fri, 7 Oct 2005, Rob Rypka wrote:
    >
    > > 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...

    >
    > See my previous post -- it shows the difference (between reject! and
    > my sense of select!), which is in the return values.


    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.

    > > In all honesty, I don't care what it's called, but reject! feels like
    > > it should have an opposite.

    >
    > Similarly (in case it's unclear), I have no underlying objection to
    > the idea of a reject! opposite :)


    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 ary.select { |e| yield e }
    rejected =3D ary.reject { |e| yield e }
    rebuilt =3D selected + rejected
    (rebuilt - ary).empty? and (ary - rebuilt).empty?
    end

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

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

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

    On Fri, 7 Oct 2005, Jacob Fugal wrote:

    > On 10/7/05, David A. Black <> wrote:
    >> Hi --
    >>
    >> On Fri, 7 Oct 2005, Rob Rypka wrote:
    >>
    >>> 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...

    >>
    >> See my previous post -- it shows the difference (between reject! and
    >> my sense of select!), which is in the return values.

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


    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

    --
    David A. Black
    David A. Black, Oct 7, 2005
    #15
  16. Geert Fannes

    Mark Hubbart Guest

    On 10/7/05, Jacob Fugal <> wrote:
    > On 10/7/05, David A. Black <> wrote:
    > > Hi --
    > >
    > > On Fri, 7 Oct 2005, Rob Rypka wrote:
    > >
    > > > 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...

    > >
    > > See my previous post -- it shows the difference (between reject! and
    > > my sense of select!), which is in the return values.

    >
    > 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.
    >
    > > > In all honesty, I don't care what it's called, but reject! feels like
    > > > it should have an opposite.

    > >
    > > Similarly (in case it's unclear), I have no underlying objection to
    > > the idea of a reject! opposite :)

    >
    > 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 ary.select { |e| yield e }
    > rejected =3D ary.reject { |e| yield e }
    > rebuilt =3D selected + rejected
    > (rebuilt - ary).empty? and (ary - rebuilt).empty?
    > end
    >
    > I propose select! and reject! should have a similar tautology:
    >
    > 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?
    > end


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

    ...it 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_box.select! {|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.

    cheers,
    Mark
    Mark Hubbart, Oct 7, 2005
    #16
  17. Geert Fannes

    Jacob Fugal Guest

    On 10/7/05, Mark Hubbart <> wrote:
    > On 10/7/05, Jacob Fugal <> wrote:
    > > 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 ary.select { |e| yield e }
    > > rejected =3D ary.reject { |e| yield e }
    > > rebuilt =3D selected + rejected
    > > (rebuilt - ary).empty? and (ary - rebuilt).empty?
    > > end
    > >
    > > I propose select! and reject! should have a similar tautology:
    > >
    > > 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?
    > > end

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


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

    > 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?}
    >
    > ...it 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_box.select! {|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.


    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.

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


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

    Under David's interpretation of "select!", this function would rarely
    return true, whereas I would expect it to always return true.

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


    I'll concede that, but IMNSHO consistency between the non-bang and
    bang versions seems more important.

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

    Rob Rypka Guest

    On 10/7/05, Mark Hubbart <> wrote:
    > 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.


    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
    Rob Rypka, Oct 7, 2005
    #18
  19. Geert Fannes

    Rob Rypka Guest

    On 10/7/05, Rob Rypka <> wrote:
    > 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).


    Jacob and others are free to continue the fight in my pseudo-absense :)

    --
    Rob
    Rob Rypka, Oct 7, 2005
    #19
  20. On Sat, 8 Oct 2005, Jacob Fugal wrote:

    > On 10/7/05, Mark Hubbart <> wrote:
    >
    >> 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.

    >
    > I'll concede that, but IMNSHO consistency between the non-bang and
    > bang versions seems more important.


    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

    --
    David A. Black
    David A. Black, Oct 7, 2005
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    5
    Views:
    336
  2. Ralf Wahner
    Replies:
    5
    Views:
    614
    Bob Foster
    Dec 24, 2003
  3. Erik Veenstra

    Hash#select and Hash#reject

    Erik Veenstra, Sep 21, 2005, in forum: Ruby
    Replies:
    0
    Views:
    103
    Erik Veenstra
    Sep 21, 2005
  4. Alexander Presber
    Replies:
    50
    Views:
    441
    Trans
    Jun 25, 2007
  5. Srijayanth Sridhar
    Replies:
    19
    Views:
    580
    David A. Black
    Jul 2, 2008
Loading...

Share This Page