Skip to content

Add Enumerable#without #19157

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 2, 2015
Merged

Add Enumerable#without #19157

merged 1 commit into from
Mar 2, 2015

Conversation

todd
Copy link
Member

@todd todd commented Mar 2, 2015

Re: #19082

I mostly took the code @dhh provided in the aforementioned issue and made a minor tweak after reviewing the relevant Ruby source and running some benchmarks - Array#reject is actually slower than Array#-, so I'm conditionally calling - on the enumerable if it's an Array. I can provide some benchmarks if anyone would like to see them. I'd also love for someone more well-versed in Ruby internals to take a look at this if they have the time.

# => ["David", "Rafael"]
def without(*elements)
if is_a? Array
self - elements
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about overriding this method separately in an Array core extension?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 to overwriting in an Array core extension. We do that with other methods like blank? etc.

@dhh
Copy link
Member

dhh commented Mar 2, 2015

Looking good besides for the type check 👏

#
# people = ["David", "Rafael", "Aaron", "Todd"]
# people.without "Aaron", "Todd"
# => ["David", "Rafael"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add comment # before =>:

# => ["David", "Rafael"] ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other examples in this file use the same style.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👌 Sorry.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries! Happy to change this to be more consistent with preferred style in another PR 😉

@dhh
Copy link
Member

dhh commented Mar 2, 2015

Great work on this 👍

dhh pushed a commit that referenced this pull request Mar 2, 2015
@dhh dhh merged commit fc91616 into rails:master Mar 2, 2015
@dhh
Copy link
Member

dhh commented Mar 2, 2015

Failing the build: https://travis-ci.org/rails/rails/jobs/52689785#L1077

We need to require what adds #in?.

@JuanitoFatas
Copy link
Contributor

@dhh Added in #19161.

@egilburg
Copy link
Contributor

egilburg commented Mar 2, 2015

@JuanitoFatas the dependency require should be in code and not in test, otherwise the test doesn't test actual scenario with someone only including that specific file, which would break for them.

But given that this is low-level helper method, better to avoid another layer of abstraction and just check elements.include?(element).

@dhh
Copy link
Member

dhh commented Mar 2, 2015

Wups. I should have caught that. What @egilburg said.

@dhh
Copy link
Member

dhh commented Mar 2, 2015

Even better 👍

On Mar 1, 2015, at 19:21, Eugene Gilburg [email protected] wrote:

@JuanitoFatas the dependency require should be in code and not in test, otherwise the test doesn't test actual scenario with someone only including that specific file.

But given that this is low-level helper method, better to avoid another layer of abstraction and just check elements.include?(element).


Reply to this email directly or view it on GitHub.

@JuanitoFatas
Copy link
Contributor

@egilburg @dhh Sorry let me fix that.

@todd
Copy link
Member Author

todd commented Mar 2, 2015

Huh - didn't run across that in my own testing. Sorry about that. I like @egilburg's solution as well.

@todd todd deleted the enumerable_without branch March 2, 2015 03:30
@matthewd
Copy link
Member

matthewd commented Mar 2, 2015

grouping.rb?

@todd
Copy link
Member Author

todd commented Mar 2, 2015

Seemed like the most appropriate place to put the new method given the presence of #split in the same file. Is there a better location you can think of?

dhh pushed a commit that referenced this pull request Mar 2, 2015
@dhh
Copy link
Member

dhh commented Mar 2, 2015

@matthewd Agree, moved it to Access. No worries, @todd it wasn't immediately clear where it should go. But I think it belongs between in access.

@todd
Copy link
Member Author

todd commented Mar 2, 2015

👍

tenderlove added a commit that referenced this pull request Mar 5, 2015
* master: (63 commits)
  Revert "delete unused method"
  Revert "mutate the transaction object to reflect state"
  be optimistic about missing route keys
  use arg size for parallel iteration
  ask the routes objects for its Rack env key
  delete unused method
  mutate the transaction object to reflect state
  ask the txn for it's state, not a state object
  change if! to unless
  Remove unneeded comment. [ci skip]
  Move Array#without from Grouping to Access concern and add dedicated test (relates to #19157)
  tests, favor `drop_table` and `:if_exists` over raw SQL.
  Skip the failing tests on Rubinius for now
  Remove not needed .tap
  Wrap inline rescue with or-equal calls
  [ci skip] Fix a typo for PostgreSQL text limit, GB instead of Gb.
  Avoid Ruby versions check on Rubinius
  Make private methods private
  Remove !has_transactional_callbacks? check
  Test against the mail gem's edge
  ...

Conflicts:
	actionpack/lib/action_dispatch/http/url.rb
	actionpack/lib/action_dispatch/routing/route_set.rb
@aripollak
Copy link

Has there been any talk about moving this to except to mirror Hash#except, since the behavior should already be the same for Hashes?

@dhh
Copy link
Member

dhh commented Mar 9, 2015

That's a good thought, but I don't think it reads as naturally: @people.without(Current.creator) reads better to me than @people.except(Current.creator). If anything, maybe it's a pointer that Hash#except should have a #without alias when that's the more natural flow.

@aripollak
Copy link

I think they both read fine 😁

@dhh
Copy link
Member

dhh commented Mar 9, 2015

We’re not going for “fine” here ;). It’s a comparative study and to me there’s no contest: The code reads much clearer with #without.

On Mar 9, 2015, at 15:13, Ari Pollak [email protected] wrote:

I think they both read fine


Reply to this email directly or view it on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
7 participants