How is using reduce writing your own reduce ?

I believe that without self it would not know what iterable object it was iterating over.

So without specifying 'self' it just forwards it to the existing upcase method?

Gives the result wanted? It's solved.

I took it as implied that I was recreating zip. Not re-using it.

Wow I just saw this. Talk about a delayed response. You make a good point about any? having its own cost, however say that @even and @is_even were used so that both methods could be lazy cached. Now someone needs to update @is_even everytime they update @even, and know to do that. For me, the cost of the any? lookup is not worth the complexity or cost of possible side effects caused later on. In the case of ActiveRecord, cached queries are supported so you could just use that instead. You still incur the lookup cost but again you don't have the dependency and possible side effect issues.

However it would be a very cool extension of this kata's design to have something like this:

attr_lazy :foos do
  # Build some data relation, e.g. an ActiveRecord::Relation instance.
end

# this method is dependant on :foos and should be reset if foos is reset
attr_lazy :foos?, [:foos] do
  foos.any?
end

The method could even be smart enough to see that a foo? method is dependent on its non-? version method of the same name and thus automatically use a different name (such as @is_foo) - though that might be too magical.

@ColbyDauph is correct about the purpose of the Kata. It is intended to make new Rubyists aware of existing features, which means that this solution is "really solving it". However, I'm not a big fan of Kata being used this way and would much rather have problems which challenged the user to create his or her own solution.

I agree that this isn't really solving it, though it is an acceptable solution. Afterall since he gave you the link, it's not hard to realize that there is a method that will perform the task for you. That being said, you get more out of it as a beginner trying to solve it and knowing that there is a shortcut for it.

..I thought the point of this kata was rewriting the upcase method?

I disagree, and will say the same thing I did in response to the comment "That's cheating..." on one of @bellmyer's other "Enumerable Magic" Katas: "Enumerable Magic #2 - True for Any?".

--

The spirit of these simple kata is basic language exploration, the description contains a direct link to documentation on enum#one, and nowhere does it state that the use of enum#one is disallowed (nor is it disabled).

The purpose here is to teach beginners about enum#one, not to force more advanced Rubyists to replicate native functionality.

Also, as @ZozoFouchtra has pointed out: "This is the solution of @bellmyer himself (this Kata's sensei)".

This isn't really solving it, it's just using the method they ask you to implement..

As far as I can tell there is no way to prevent a user from submitting a solution that uses #inject. Maybe that means this problem is not suitable for a kata.

Some current solutions return 0 for [0].accumulate(nil, :+),

which differs from [0].inject(nil, :+) which raises an error NoMethodError: undefined method '+' for nil:NilClass

I'd suggest adding a test case similar to

Test.expect_error { [0].accumulate(nil, :+) }

Please do explain what s is and where it comes from.

OK, that is acceptable. Thanks for explaining.

Just so you know where my point of view comes from, here are some practical cases where the ability to use both attr_lazy :even and attr_lazy :even? to memoize results would be useful.

# The memoized result of `even` is a lazy enumerator
attr_lazy :even do
  @numbers.lazy.map { |n| fib(n) }.select(&:even?)  # where fib(n) returns the Fibonacci number F(n)
end

attr_lazy :even? do
  # Enumeratar::Lazy#any? is a potentially expensive operation since
  # it forces iteration until a value is yielded. If there is a need
  # to invoke this multiple times it is safest to memoize the result.
  even.any?
end

attr_lazy :foos do
  # Build some data relation, e.g. an ActiveRecord::Relation instance.
end

attr_lazy :foos? do
  foos.any?  # Executes a query against the data store each time it is invoked. Memoize if invoked more than once.
end