From: "David A. Black" Date: 2009-12-25T19:46:56+09:00 Subject: [ruby-core:27322] Re: select! This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1926193751-1801687880-1261738005=:32064 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Hi -- On Thu, 24 Dec 2009, Gavin Sinclair wrote: > On Thu, Dec 24, 2009 at 10:19 AM, David A. Black wrote: > >>> |Is there any reason there's no select! >>> >>> Enumerables cannot have bang method, since they are not always >>> mutable. �The reason we don't have Array#select! is that I feel the >>> word select means picking up elements, not removing non-selecting >>> elements. �But I once felt same way to map! and (English speaking) >>> people persuaded me, so same thing could happen on select! as well. >> >> I agree with you. The idea of a destructive select makes no sense to >> me. Selecting implies that there's a result set that's separate from >> the original collection. > > I think it's fine. It's an aggressive selection, like selecting a > sports team from a squad of available players. But that's the thing; it's the original squad, not the selected team, that's analogous to the array. Say you've got a squad of players, standing in a line: SQUAD: Joe Jim Jill Jack Jason Jeff Joan You select a bunch of them for a team and ask them to step forward, on the understanding that they will no longer be part of the original squad/pool of players SQUAD: Joe Jill Jack Jeff TEAM : Jim Jason Joan The squad (i.e., the original "object" from which you have made a selection) now consists of the people who were *not* selected for the team, not those who were. Aggressiveness isn't relevant. If you say to Jim, Jason, and Joan: "You have been *aggressively* selected for the team!", that should still mean that they're on the team, not that they're back in the original player pool (the array/object), let alone that they are now the sole occupants of that original pool. Select and reject are not symmetrical or opposite operations; they're two names for the same process, namely identifying a result set based on selection criteria from a collection. However this process happens, you end up with the original collection and the result set. The only decision to be made is whether or not the members of the result set can also be in the original collection. A destructive reject means: having made this separation of original collection and result set, make the separation permanent. A destructive select, in the sense that's being suggested here, would mean: having made the separation, replace the original collection with the result set. That's a completely new twist, and one that isn't implied in any way by the original idea of "select". That's why "keep" makes more sense as a name for "reduce the original collection to the matching elements". It's a simple statement of the semantics of this particular operation. (I almost wish reject! were called "discard" or something. I think the similarity in sound between reject and select suggests a symmetry that really isn't in the semantics.) David -- David A. Black Senior Developer, Cyrus Innovation Inc. THE COMPLEAT RUBYIST, Ruby training with Black/Brown/McAnally! January 22-23, Tampa, Florida Info and registration at http://www.thecompleatrubyist.com --1926193751-1801687880-1261738005=:32064--