Problems dealing with Enumerable protocol

The discussion is about a Redis-backed Elixir library whose queries can be chained and then treated as Enumerable. The author wants Enum.take and Enum.at to pass useful information to Redis so only the needed items are fetched, but the replies say the API should expose limit and offset directly instead of relying on Enum to do that work.

José Valim says the distinction between database and in-memory or stream operations matters because of performance and latency, and he also says count and member? should be explicit. Booker Bense suggests using a Stream if short-circuiting is the goal, and Peter Hamilton recommends providing semantically similar Red functions such as take and at.

Reading notes

#

• The library builds Redis queries that can be chained before fetching happens.
• The author wants Enum.take and Enum.at to use the requested position or count when talking to Redis.
• José Valim says explicit limit and offset are the correct approach.
• He separates database behavior from in-memory and stream behavior because their performance and latency differ.
• He says count and member? should also be explicit.
• Booker Bense says short-circuiting via Enum.take requires a Stream rather than an Enumerable.
• He suggests Stream.resource for wrapping the Redis lookup.
• Peter Hamilton suggests Red should provide functions like take and at with similar results but different execution properties.
• José Valim later says laziness is a property of the module chosen, not of the collection itself.