Range Based Property List Operations

[Gleethos]

I think we should have things like:

• removeBetween(int,int)
• setBetween(int,int,T)
• setBetween(int,int,Var<T>)

[Mazi-S]

Sounds great. Maybe we should add popBetween as well?

[Mazi-S]

How would you name the methods? between as you suggested or maybe range.

between

• removeBetween(int from, int to)
• popBetween(int from, int to)
• setBetween(int from, int to, T value)
• setBetween(int from, int to, Var<T> value)

range (my favorite; I think a bit clearer, but I'm fine with between too)

• removeRange(int from, int to)
• popRange(int from, int to)
• setRange(int from, int to, T value)
• setRange(int from, int to, Var<T> value)

at (my least favorite)

• removeAt(int index, int size)
• popAt(int index, int size)
• setAt(int index, int size, T value)
• setAt(int index, int size, Var<T> value)

[Gleethos]

Great suggestions! After some thinking, I have to agree with you that the range based method names are definitely preferable to the between based naming. Although I do find between sounds more intuitive, there is the problem of it being ambiguous with respect to what the things passed to the methods are. "Between" may suggest that the passed arguments are items in the lists, whereas "range" unambiguously tells that it is indices. For number based property lists, "between" can be very confusing.

So I would definitely support implementing:

• removeRange(int from, int to)
• popRange(int from, int to)
• setRange(int from, int to, T value)
• setRange(int from, int to, Var<T> value)

With respect to the third suggestions, the at based approach, I would argue that these methods are not actually synonymous alternatives as their second argument is not an ending index, like for a traditional range, but instead an offset value! So they are semantically a little different. So I would actually argue that they may be able to serve a complementary role when an API user has an algorithm which uses an offset instead of a final index.

So in this example:

int start = calcStart();
int size = numberOfElementsToRemove();
myProperties.removeAt(start, size);

The user could use removeAt(start, size) instead of removeRange(start, start+size), which is arguably also a useful way to do a range based operation.

But I do not have a particularely strong opinion on it, it would however be consistent with the other at based methods.

What do you think?

[Mazi-S]

So you are suggesting that we have both the range and at methods in our API?

I totally agree with what you said. For me, the at methods would be a nice addition to the range methods and would make the code a bit cleaner, even though they do not introduce any new behavior.

[Gleethos]

So you are suggesting that we have both the range and at methods in our API?

Yes exactly