4 ms·

That makes some sense to me, but technically that object at that point is not an "Enumerable" so you are essentially faking it knowing that it would be once exe

That makes some sense to me, but technically that object at that point is not an "Enumerable" so you are essentially faking it knowing that it would be once executed. Is there some significant benefit to it returning true for Enumerable that I'm just missing?

masklinn 15y ago
> That makes some sense to me, but technically that object at that point is not an "Enumerable" Why not? An enumerable is anything that can be enumerated, the query object holds the potential of being enumerated, it's just an actual underlying query away but that's of no relevance to the interface. The only reason why it's not "technically Enumerable" at that point is... that it does not implement Enumerable's interface. > so you are essentially faking it knowing that it would be once executed. Why would you be faking anything? Is LINQ faking anything when it produces IEnumerable<T> after each "operation"? > Is there some significant benefit to it returning true for Enumerable that I'm just missing? Interface simplicity? Workflow simplicity? I see no reason for it not to? Get rid of the useless `all` method?
- akmiller 15y ago
  I don't think there is much difference between what ActiveRecord is doing and what LINQ does. The main LINQ object is an IQueryable object that implements IEnumerable. However, IEnumerable is not the object that has all the enumerator methods on it. That is IEnumerator. The only method IEnumerable has is the GetEnumerator method which returns the IEnumerator object. So, in actuality, the "all" method in ActiveRecord kind of acts like the IEnumerable interface in returning the actual enumerator object.
- burke 15y ago
  Strictly speaking, you're not actually enumerating for a lot of the potential use-cases of enumerable methods. For example, say #reject were implemented: User.where(admin: true).reject(office: current_user.office) There are two ways to implement this: One by literally iterating over the result set and filtering it; and Two by adding a projection to the query builder. In the second case, it is small-e enumerable, but not strictly Enumerable, since Enumerable very explicitly defines each method in terms of #each. That doesn't make sense for a query builder. It could implement Enumerable and override every single method, but the point a few people are making here and in the post comments is that checking kind_of?(Enumerable) is non-idiomatic. Including modules for semantic meaning is appealing to programmers from certain backgrounds for completely understandable reasons, but simply checking for the presence of the method needed is more clear -- ie. respond_to?(:each) is the intended solution. TL;DR: Modules aren't Interfaces.

masklinn 15y ago

> That makes some sense to me, but technically that object at that point is not an "Enumerable" Why not? An enumerable is anything that can be enumerated, the query object holds the potential of being enumerated, it's just an actual underlying query away but that's of no relevance to the interface. The only reason why it's not "technically Enumerable" at that point is... that it does not implement Enumerable's interface. > so you are essentially faking it knowing that it would be once executed. Why would you be faking anything? Is LINQ faking anything when it produces IEnumerable<T> after each "operation"? > Is there some significant benefit to it returning true for Enumerable that I'm just missing? Interface simplicity? Workflow simplicity? I see no reason for it not to? Get rid of the useless `all` method?

akmiller 15y ago
I don't think there is much difference between what ActiveRecord is doing and what LINQ does. The main LINQ object is an IQueryable object that implements IEnumerable. However, IEnumerable is not the object that has all the enumerator methods on it. That is IEnumerator. The only method IEnumerable has is the GetEnumerator method which returns the IEnumerator object. So, in actuality, the "all" method in ActiveRecord kind of acts like the IEnumerable interface in returning the actual enumerator object.
burke 15y ago
Strictly speaking, you're not actually enumerating for a lot of the potential use-cases of enumerable methods. For example, say #reject were implemented: User.where(admin: true).reject(office: current_user.office) There are two ways to implement this: One by literally iterating over the result set and filtering it; and Two by adding a projection to the query builder. In the second case, it is small-e enumerable, but not strictly Enumerable, since Enumerable very explicitly defines each method in terms of #each. That doesn't make sense for a query builder. It could implement Enumerable and override every single method, but the point a few people are making here and in the post comments is that checking kind_of?(Enumerable) is non-idiomatic. Including modules for semantic meaning is appealing to programmers from certain backgrounds for completely understandable reasons, but simply checking for the presence of the method needed is more clear -- ie. respond_to?(:each) is the intended solution. TL;DR: Modules aren't Interfaces.