Incorrect use of No_entry_value in primitive arraylists

[Rob Eden]

There are several problems with no_entry_value in arrayLists:

1. The equality of arraylists does not consider the no_entry_value. For example, create two TIntArrayLists, one with no_entry_value -1 and one with no_entry_value 0. In both lists, add the no_entry_value to the list. The result of equals should be true, but is false.
2. The minimum and maximum should never return the no_entry_value.
3. The sum should not consider the no_entry_value

I see no need for a no_entry_value in lists. remove it from the template code alltogether.

[Rob Eden]

Original SF bug

Comments from original bug:

Anonymous

This holds for linkedlists as well

Rob Eden

I agree, no reason for no_entry_value in lists.

[Jim Davies]

I'm investigating this issue currently.

[Jim Davies]

Ok, all those are still issues. I can see a two use cases for the no_entry_value. These are:

1. If you want to be able to have an entry which is 0, than you need to be able to change the no_entry_value to something else;
2. When using a decorator, there is no other way to represent 0 in a list.

I can think of lots of ways of "dealing" with it. For completeness I'll list both those already suggested, and then add a few extra ideas of my own:

1. Accept 0 as null;
2. Have a set number which represents the null value;
3. Update all the null entries to a new null entry value when the current null entry value collides with a new value;
4. Create a table of substitute values appended to whenever a collision with a newer substitution occurs;
5. Create a bitmap for the values in the array, indicating their status;
6. For floating point types, map the null value to a custom NaN value.

So, we currently have 2. 1 is just 2 with a value of 0, which is currently the default. 1 has the problem that it breaks the max and min methods (I can expand on that if anyone wants me to; just ask). 3, 4 and 5 are completely new functionality, and I may have a go at implementing them in experimental, but they're not really in the scope of this issue. 6 is 2 with some carefully constructed values for floats and doubles. The good point about 6 is that its no extra code, but it should be almost impossible for a collision to occur.

Therefore, I'll fix the code, as I think that it is needed. Also, I'll try to do it in what I feel is the spirit of the original code. Also, I'll have a look through the code and see if there is anywhere that I think also needs fixing due to this bug.