IMMUTABLE_TREE_R0

[stefan]

wiki page: IMMUTABLE_TREE_R0

[meddle]

• I think you should say in which branch you will work
• The test cases are not a requirement they are always mandatory.
• The list is for the requirements.
• You have interface for the list, you should use it because in the big refactoring everybody is using it.

Take these things in mind for the design to pass :)

3p (10m)

[meddle]

So I'll fail the design:

• I told you in the analysis review, you will have to use the current ImmList interface in the second_resource_refactoring branch for your list, because the whole model is using it.
• You didn't give me design related code, you know the design code MUST be mergeable without compilation errors.
• You didn't say in which branch you worked again...
• About the tests:
  • So you have repeating code for checking the trees and operations, extract it in a test util class.
  • Use the SophieLogger to log in your tests, not System.out.println I know it's buggy, but when sending code for review you must use it.
  • Small thing, the second one is not necessary:

        assertEquals(list, tree.asList());
        assertEquals(tree.asList(), list);
    

2p (25m)

[meddle]

I think it passes, just fix your JavaDoc and pass it to the implementation review.

3.5p (1h)

[meddle]

So, I think in some places the JavaDoc is not enough, for example you could explain some of the algorithms in it... but, your choice.
Another thing is that Rado's code was not exactly by the standards, but...

3.5p (70m)

[stefan]

What is Rado's code? How it is not by the standards?
About the algorithm, I suppose you speak of Red-Black tree algorithm, which its widly available (for ex. ​http://wikipedia.org)...

[pap]

although the effort field is useles it should be a pure float without letters

[deyan]

Batch update from file query-obsoleted.csv