About Joiner and discussion about proposal of a new type, alternative to existing Joiner.

[esemplastic]

@lanzafame I did create a new issue to discuss those things we were unsure from our previous conversation, inside the PR. All users can watch and participate to this discussion now, or later on.

Please, read the previous two comments on this subject, here, before continue.

---

It's good, I am not saying the opossite, you did a great choice, I'm unsure about the Joiner at general. I understand the point of yours now and how current Joiner works for you.

I will just add my thoughts when I did create that empty interface on the beginning: the Joiner is the Divider's opossite operation/reverser , that was the reason we had a Joiner interface at the first place, to be able to do reverse operators with the UNIS model too. The example of a PathJoiner cannot be fully adressed by a Joiner, because Joiner takes only two string receivers, while a path can have many parts that you may want to join with a slash separator.

I think things like PathJoiner is a good example for a new need of type. A type of PathJoiner implementation would be better to accept an array of strings or a varadiac parts ...string rather than two strings part1 string, part2 string in order to add any number of values of parts there and return them as one (this is easy as you can imagine but it's not allign with the current Joiner /Divider reverser's outline).

To sum up,

1. Do we keep the current Joiner as a reverser of Divider , and if yes what would be the best candicate name for a new type like Joiner but variadic string as receiver?
2. If we refactor the current Joiner to accept variadic string should we do the same for the Divider? If yes then the output arguments of the Divider type should be []string instead of (string,string) to align the new Joiner

Let's start a good discussion about the cons and props of a new type or overriding the existing with some changes on Divider too (it's not late, it's a new project)!

[ianlopshire]

I can't think of any situation where the current Divider interface is preferable to one that returns []string.

My preference would be:

type Divider interface {
    Divide(original string) (result []string)
}

type Joiner interface {
    Joiner(parts ...string) (result string)
}

[ianlopshire]

I would also consider renaming Divider and Joiner to Expander and Reducer respectively.

type Expander interface {
    Expand(original string) (result []string)
}

type Reducer interface {
    Reduce(parts ...string) (result string)
}

The names Expander and Reducer cover all the functionality of Divider and Joiner but are also applicable to other situations.

Consider a coalesce function. It would end up with the signature:

func Coalesce(Validator) Reducer {
    ...
}

[esemplastic]

@ianlopshire I Agree with all, it seems the best adoption. Let's wait a while for any new recommendation or ideas!

[lanzafame]

@ianlopshire I really the concept of Expander and Reducerover that of Divider and Joiner. Much more general and flexible.

Could you please provide an example of a use of Coalesce please? I don't feel like I am quite understanding how it will be utilized. Cheers

[ianlopshire]

@lanzafame The Coalesce function would accept a Validator and return a Reducer. The resulting Reducer would return the first valid string.

// Coalesce creates a Reducer that returns the fist valid string.
func Coalesce(Validator) Reducer {
    ...
}

// NotEmpty returns false if the string is at its zero value
func NotEmpty(value string) (bool, error) {
    ...
}

value := Coalesce(NotEmpty)("", "", "foo", "bar") // value = "foo"

I'm not proposing it be part of the library (though it might make a welcome addition). I was providing it as an example where Expander and Reducer provide more flexibility than Divider and Joiner

[lanzafame]

@ianlopshire cheers. I like the flexibility it provides, so I also think it would be a welcome addition.

[esemplastic]

Hello @ianlopshire and @lanzafame sorry for being late.

You gave good examples with code-snippets, I think we agree at the new terms of old "divider" and "joiner". I'll be glad If one of you can start the conversions whenever he can (I'll be busy for the next week as well, I have to upgrade a client's project first), thank you very much for your interest and your time!