An alternative way to call the streams?

[mdlkxzmcp]

As much as I like the way of calling the streams with (limit: l, fraction_digits_limit: fl), it breaks most of the defdelegate macros as they don't support (AFAIK) passing keyword lists. So I think this is worthy of a discussion of how we want to shape the API. Now that we have so many generators, the orangeade.ex file in which all the defdelegate calls were stored is now a tiny bit messy. So wat do wat do man.

I see three ways of fixing this (I will be using the function from above as the example):

1. We add a stream(limit, fraction_digits_limit) function to the file so that there are two ways of calling it, allowing us to defdelegate from the orangeade.ex file.
2. We add a float(limit, fraction_digits_limit) function that works in the same way as the stream example above, but this allows us to minimize the noise in orangeade.ex file. (This will get rid of the , as: :stream part.
3. We leave the code as is and forget about delegation, meaning that the API is more convoluted (Orangeade.float(limit, fraction_digits_limit) vs Orangeade.Generator.Float.stream(limit: l, fraction_digits_limit: fl), but this saves us the trouble of refactoring almost all the files to support the previous two APIs.

Personally I am all for the 2. way even though it requires a bit more work.

[sebb7]

API which was shown by @Dzol during the classes and then suggested by him in the notes is very clear and understandable. I would stick to keyword lists used in it.

When it comes to defdelegate macros, I can not figure out the issue with passing keyword lists. Can you clarify @mdlkxzmcp?

Function names in current defdelegate macros can be misleading. When somebody calls Orangeade.float he can expect single float to be returned. I implemented defdelegate macros with more appropriate names and for all modules. Please see #18.

[mdlkxzmcp]

I think the way you named them is really good, and the fact, that you can just pass opts to the defdelegate macro to satisfy the keyword list in a manner that still works when called has been foreign to me. Really nice work <3

[Dzol]

We've come full circle with the API...

I liked the idea of doing the delegate functions because integer() is less verbose than Generator.Integer.stream(). This is particularly nice when we're reading the Generator and stream() parts up to three times in an example like Generator.Integer.stream(); Generator.Boolean.stream(); Generator.Float.stream(). That the name float is less descriptive, because it looks like it'll give us a float as opposed to a stream of floats, is true. However: is gen_float_stream/0 much of an improvement over the original Generator.Float.stream/0?

When functions have a common prefix like gen_ it's often an indication that they should reside in a module of their own. E.g. Gen.float or Generator.float. The module and the name-space can be used to great effect in similar cases. In my experience they're the most neglected and least appreciated construct and mechanism Elixir.

I have to finalise the class IV notes and prepare for another school so the time I can dedicate to issues and PRs on this project is going to be limited in the future. I'll take an occasional look however

[mdlkxzmcp]

Oh wow yeah that's true! I knew there was a reason why I was doing the defdelegate's that way. But it is also true that unless you remember what Orangeade does, you could mistake the behavior for something else. I guess that's why I opened this issue, to discuss the best way to go about it. Doing it as Gen.float is now my favorite way, although it does hide the fact that it is a stream. Gen.floats is also an option... Wat do wat do man [2]