Function overload for some combinators

[diogob]

since all and collect do essentially the same combination except by the shape of input and output, they would be a great candidate for function overloading. In that case we would make it easier to explain and understand these combinators, reducing the number of arbitrary names.

[diogob]

@gustavoguichard this was @douglasheldpacito idea during a pairing session where we were going back and forth both combinators

@danielweinmann I have a feeling you will also have opinions on this

[gustavoguichard]

@diogob : do you mean having the same name for both functions?

all: (...dfs: DomainFunction<T>[]) -> DomainFunction<T[]>
all: (dfs: Record<string, DomainFunction<T>>) -> DomainFunction<Record<string, T>>

[gustavoguichard]

If that is the case, I'm not sure if the complexity added will be worth it, but it would help with cases like pipe/collectSequence more than all/collect IMO

[danielweinmann]

I think having separate names is better. The learning curve might be a bit steeper, but it avoids confusion later on. Imagine the following dialog while pair-programming:

• We could use all for that instead of using an imperative fromSuccess.
• Which type?
• Oh, the one that returns an object with keys.

With separate names, and after both programmers know the names, the dialog would be:

• We could use collect for that instead of using an imperative fromSuccess.
• OK.

[diogob]

This is one of the motivations for me, since these functions differ only on the shape of the data, there is hardly a clear cut definition of which one you "should" use. So in the dialog above, any version would do (adjusting for the different types)

[danielweinmann]

I edited the dialog to remove the idea of something we "should" do. I still believe these are different concepts that deserve different names so we can reference them. Without different names, we would have to explain in more words what we're aiming for in each case.