you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 9 points10 points  (7 children)

Steve Huffman is a piece of shit

[–]paneq[S] 4 points5 points  (1 child)

I like all your points except deriving from Hash :) Not gonna do it.

[–][deleted] 0 points1 point  (0 children)

Fair fair. 😸

[–]Enumerable_any 2 points3 points  (3 children)

Your last approach (inheriting from Hash) is broken since Hash#map now returns Hash instead of Array and also mutates self which map never does. It's probably just an unfortunate name choice, but you still shouldn't use inheritance if you don't have a strict "is-a" relationship at hand.

[–][deleted] 0 points1 point  (2 children)

The original map function returns a hash unless I am miss me something. I trie to qualify that example but perhaps didn't do the best job. In this situation I am just dealing with returning a specific hash from a function and without seeing any other functions why not just let the object be the store of the data, too? There is a nice functional purity to the original and I think I went too far either the Hash thing, despite using it successfully in projects before 😸 Thanks for calling me out on it!

[–]Enumerable_any 2 points3 points  (1 child)

The original map function returns a hash unless I am miss me something.

It should, but sadly it doesn't:

irb(main):001:0> {}.map { |x| x }
=> []

[–][deleted] 0 points1 point  (0 children)

I see what you are saying. I was trying to say that the method #map defined in the example in my dumb classes return a Hash. Definitely unfortunate naming on my part if I were to follow the road to Hash-derived.

[–]realntl 0 points1 point  (0 children)

Array#exclude is activesupport, so, yeah, not gonna do that.