elm-community / list-extra

Convenience functions for working with List.

Home Page:http://package.elm-lang.org/packages/elm-community/list-extra/latest

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Rename replaceIf or setAt

pzp1997 opened this issue · comments

replaceIf and setAt are really two variants of the same kind of operation. They both replace some element(s) with a given value. Perhaps their naming should reflect this similarity. (Similar to how we have updateIf and updateAt.) Some questions to consider.

  1. Are there any advantages provided by keeping the current naming?
  2. If not, which name describes the operation better? (It may or may not be relevant to the discussion to note that Array uses the name set for a similar operation.)
  3. Perhaps out of the scope of this issue but also related, do we even need setAt and replaceIf when they are essentially equivalent to calling updateAt and updateIf with an update function of always x.

Answering question one, we've already made some major changes, so I think now is the time to cohere the names of set, replace, and update; otherwise I would be more hesitant. Maybe we should rename replaceIf to setIf.

I do think update has independent value from set and replace. Set and replace take a distinct value, where as update is agnostic on what value its updating. Without update, you have to get the value, and then replace it.

I agree with you about the timing due to having already made breaking changes for the next version. Regarding # 3, I was actually suggesting that we get rid of replaceIf and setAt. It is quite simple for a user to replace their behavior using updateIf and updateAt.

Like if they want to replace, they should do something like updateAt 0 (always 1) [ 0, 1, 2 ]?

Correct, that's all we would be doing in our implementation anyway. (Currently the implementation for setAt is more complicated, but that should change once I find the time to finish #55.) The convenience it provides is pretty minimal.

One point in favor of keeping it would be that using always might be non-obvious to some people (but I do not think that this is the case for the vast majority of Elm developers). It is already here and I suppose we have very little to lose by keeping it.

I'm somewhat indifferent on the matter of removing it, but I do think that if we choose to keep it either replaceIf should be renamed to setIf or setAt should be renamed to replaceAt.

I think keeping it is a much better option. Its conceptually simplest that their would be different functions for setting, updating, and replacing, even if a little bit of reasoning can show that an update is a kind of replace. More functions necessary to execute an update (as is the case in always 1, make things less readable too.

Now that I've had some time to think about it, I agree with you. My vote is in favor of renaming replaceIf to setIf then.

@Chadtech Let me know if you want a PR for this.

Closing since we followed through on this.