I've never passed an argument to a .count method in my 9 years of writing ruby
code. I would never think to do such a thing and such a thing would never occur
to me (passing anything — block or otherwise — to a count method)
Here's the efficiency problem with your code & proposal:
> submissions.to_a.count(&:incomplete?)
This code inherently encourages a code smell design— the objects must first be
retrieved from the database before they are evaluated for incomplete?. This is
slow, and won't scale.
Instead, you would do well to define incomplete as a scope and not a method and
instead rewrite it like so:
submissions.incomplete.count
That will correctly use Active-Relation (A-Rel) objects to create the right
SQL, something like
SELECT count(*) FROM submissions where incomplete = 1
Otherwise, you fetch all submissions from the database and then call
incomplete? on each one, creating both an N+1 query problem and also a scaling
problem because you have to instantiate each object (object instantiation is
not fast) just to find out if it responds true or false.
For efficiency alone, I would be :thumbs_down: on a change like this as it
would encourage this kind of bad coding practices.
-Jason
> On May 15, 2017, at 6:16 PM, Matt Wean <matthew.w...@gmail.com> wrote:
>
> I just ran into this issue, and I would actually call it a bug since it
> causes very unexpected behavior:
>
> > User.count { |user| user.not_a_method! }
> => 10
> So the block isn't even being evaluated. I'm fine if we don't delegate to
> Enumerable, but I would expect #count to at least raise an error if a block
> is given so people don't accidentally try to count with a predicate and get
> the wrong answer.
>
>
> On Friday, February 1, 2013 at 10:12:36 AM UTC-8, Matt Jones wrote:
>
> On Jan 31, 2013, at 1:35 PM, Christian Romney wrote:
>
> > Hi all,
> >
> > I realize this behavior is by design, and in some respects the right thing
> > to do. It also pre-dates the addition of Enumerable#count. I'm wondering,
> > however, if it's possible/desirable to allow the caller to access the
> > Enumerable versions under certain conditions. I originally wrote the up as
> > an issue, but was informed this would be the better venue. I'm linking to
> > the original issue on Github because the syntax highlighting is nice.
> >
> > https://github.com/rails/rails/issues/9132
> > <https://github.com/rails/rails/issues/9132>
>
> In the example in the issue, wouldn't this work nearly as well:
>
> def incomplete_submissions
> submissions.to_a.count(&:incomplete?)
> end
>
> In short, if you want the Enumerable behavior, just ask for it...
>
> --Matt Jones
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com
> <mailto:rubyonrails-core+unsubscr...@googlegroups.com>.
> To post to this group, send email to rubyonrails-core@googlegroups.com
> <mailto:rubyonrails-core@googlegroups.com>.
> Visit this group at https://groups.google.com/group/rubyonrails-core
> <https://groups.google.com/group/rubyonrails-core>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
----
Jason Fleetwood-Boldt
t...@datatravels.com
http://www.jasonfleetwoodboldt.com/writing
If you'd like to reply by encrypted email you can find my public key on
jasonfleetwoodboldt.com <http://jasonfleetwoodboldt.com/> (more about setting
GPG: https://gpgtools.org)
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
