Hash#select returns an array but Hash#reject returns a hash...
in [Ruby]
|
Prev: Problem with Ruby Multithreading
Next: meaning of %w
From: Jeremy McAnally on 1 Jul 2008 11:42 OK, then there's a box of books. You get another box. You move books that you like from the first box to the second and ditch the others. It's all the same and the minutia aren't really that important when describing the general behavior. I think the analogy works perfectly fine to get the point across about the behavior of the method. --Jeremy On Tue, Jul 1, 2008 at 10:28 AM, Rick DeNatale <rick.denatale(a)gmail.com> wrote: > On Tue, Jul 1, 2008 at 10:18 AM, David A. Black <dblack(a)rubypal.com> wrote: > >> Hi -- >> >> >> On Tue, 1 Jul 2008, Rick DeNatale wrote: >> >> >>> I'm having a hard time making the connection between this analogy and the >>> methods. >>> >>> In the first case one could say that we end up with two lines, the >>> 'original' one and the line of rejects. >>> >>> But first of all, x.reject leaves x alone so the original 'line' is >>> unchanged. >>> >>> And why can't we see your select example exactly the same way, except with >>> the resultant line of 'selects' just closer to you. >>> >>> >> It's specifically not about the exact objects, though. As I said, >> "same line" in this model doesn't map to "same object". Rather, the >> analogy has to do with types of structure or container. >> >> Here's another, perhaps better analogy. You've got a shelf of books, >> and you've got an empty box. You select some books from the shelf, and >> put them in the box. Now you've got two structures: a shelf, and a >> box. >> >> If you were describing this operation, you'd say: "I selected some >> books and put them in a box." The box of books is the result of the >> operation, and is structurally different from the shelf. The point is >> not that this is the only way it can be done, but that it *can* be >> done this way. It's reasonable to select from a collection into >> something that is not only a different collection, but a different >> container type. >> >> Now, if you do it reject-wise, you take the books you don't want and >> throw them out the window. The box never enters into it. You're not >> selecting, so you don't care about observing or measuring the books >> that you're removing from the shelf. >> > > I still have the same problem with this analogy. > > reject and select are not about the books. They don't move books from one > collection to another. They BOTH return a new collection which references > some of the objects referenced by the receiver. > > select returns a collection of all of the objects in the receiver which meet > the criterion specified by the block, reject returns a collection of all the > objects in the receiver which DON'T meet the criterion specified by the > block. > > The fact that Ruby <1.9 tends to return arrays rather than something of the > same species as the receiver on such methods was something I had to get used > to after my Smalltalk experience. > > And, compatibility aside, I think that 1.9 is going in the right direction > here. > > -- > Rick DeNatale > > My blog on Ruby > http://talklikeaduck.denhaven2.com/ > -- http://jeremymcanally.com/ http://entp.com Read my books: Ruby in Practice (http://manning.com/mcanally/) My free Ruby e-book (http://humblelittlerubybook.com/) Or, my blogs: http://mrneighborly.com http://rubyinpractice.com
From: Robert Dober on 1 Jul 2008 15:57 On Tue, Jul 1, 2008 at 4:24 PM, David A. Black <dblack(a)rubypal.com> wrote: > Hi -- > > On Tue, 1 Jul 2008, Srijayanth Sridhar wrote: > >> On Tue, Jul 1, 2008 at 7:26 PM, Robert Dober <robert.dober(a)gmail.com> >> wrote: >>> >>> On Tue, Jul 1, 2008 at 3:42 PM, Rick DeNatale <rick.denatale(a)gmail.com> >>> wrote: >>> I rather agree with Rick although David has a point too. >>> >> >> Yeah I agree with Rick as well or I wouldn't have asked the question >> in the first place. > > Rick made some points about in-place changes vs. copies of Ruby > objects that I agree with, but that wasn't what my post was about :-) > See my last one too. > Actually I think the most important thing about this is, yes I know you guessed and you disagree, consistency;) But give me a chance, it can be consistent that whatever.reject.class == whatever.class and whatever.select.class == Array. That was exactly why I named my Hash returning methods hselect, vselect and kselect. However personally I would prefer a different kind of consistency on this one, as some others would, I do not even daresay that we are a majority ;). Cheers Robert
From: David A. Black on 1 Jul 2008 22:07 Hi -- On Wed, 2 Jul 2008, Robert Dober wrote: > On Tue, Jul 1, 2008 at 4:24 PM, David A. Black <dblack(a)rubypal.com> wrote: >> Hi -- >> >> On Tue, 1 Jul 2008, Srijayanth Sridhar wrote: >> >>> On Tue, Jul 1, 2008 at 7:26 PM, Robert Dober <robert.dober(a)gmail.com> >>> wrote: >>>> >>>> On Tue, Jul 1, 2008 at 3:42 PM, Rick DeNatale <rick.denatale(a)gmail.com> >>>> wrote: >>>> I rather agree with Rick although David has a point too. >>>> >>> >>> Yeah I agree with Rick as well or I wouldn't have asked the question >>> in the first place. >> >> Rick made some points about in-place changes vs. copies of Ruby >> objects that I agree with, but that wasn't what my post was about :-) >> See my last one too. >> > Actually I think the most important thing about this is, yes I know > you guessed and you disagree, consistency;) > But give me a chance, it can be consistent that whatever.reject.class > == whatever.class and > whatever.select.class == Array. That was exactly why I named my Hash > returning methods hselect, vselect and kselect. It depends on the class, though. Neither File#select nor File#reject is going to be return a File object. David -- Rails training from David A. Black and Ruby Power and Light: Intro to Ruby on Rails July 21-24 Edison, NJ Advancing With Rails August 18-21 Edison, NJ See http://www.rubypal.com for details and updates!
From: Robert Dober on 2 Jul 2008 08:17 On Wed, Jul 2, 2008 at 4:07 AM, David A. Black <dblack(a)rubypal.com> wrote: > It depends on the class, though. Neither File#select nor File#reject > is going to be return a File object. OMG, but are these names really baring the same semantic meaning? Robert
From: David A. Black on 2 Jul 2008 08:49
Hi -- On Wed, 2 Jul 2008, Robert Dober wrote: > On Wed, Jul 2, 2008 at 4:07 AM, David A. Black <dblack(a)rubypal.com> wrote: > >> It depends on the class, though. Neither File#select nor File#reject >> is going to be return a File object. > OMG, but are these names really baring the same semantic meaning? It's all Enumerable-based, ultimately, though some classes do overrides. David -- Rails training from David A. Black and Ruby Power and Light: Intro to Ruby on Rails July 21-24 Edison, NJ Advancing With Rails August 18-21 Edison, NJ See http://www.rubypal.com for details and updates! |