Resolve Issues #21, #23, and #24

[pankaj-bind]

Issue #21: About NilNode
Problem: CTAVLNode methods like childrenDo:, do:, height, and isBalanced contain explicit ifNil: checks, which you noted could be avoided with a proper Null Object pattern.
Fix: Enhanced CTAVLNilNode to implement all necessary methods (e.g., childrenDo:, do:, height) with no-op or default behavior, and removed ifNil: checks from CTAVLNode methods, relying on polymorphism.

Issue #23: Can we get rid of isNilNode
Problem: CTAVLTree >> size uses isNilNode to check if the root is a CTAVLNilNode, which is unnecessary with a Null Object pattern.
Fix: Removed isNilNode from the class hierarchy, introduced a polymorphic nodeSize method (0 for CTAVLNilNode, recursive count for CTAVLNode), and refactored CTAVLTree >> size to simply call root nodeSize.

Issue #24: Can we get rid of AVLTree >> isNil
Problem: CTAVLTree >> isNil checks if the root is a CTAVLNilNode, which you questioned as redundant for a tree’s API.
Fix: Removed CTAVLTree >> isNil, relying on isEmpty (inherited from Collection) which uses size = 0, made possible by the nodeSize refactoring.

[pankaj-bind]

Hey @Ducasse, I'm aware of the issue I created previously (#19), but I found that it may cause a conflict with this Nill issue. That's why I thought I should resolve this one first.

[Alokzh]

Hi @pankaj-bind Thnx for the PR but I was already working on explicit check issue ( as discussed in #22 ) & was almost ready with PR.

However if Stephan thinks this implementation is ok we can merge it.
Also some suggestion I think we should only have one approach either childrenDo: or children/withAllChildren: , I think childrenDo: is better one.

[pankaj-bind]

@Alokzh if you think you can make it, you are good to go buddy, @Ducasse please look for his PR. I'm closing mine.

[Alokzh]

@pankaj-bind I don't have any problem with your PR ( just inform from next time that you are interested ).
Why did you close it ? Only few changes were needed in your PR I think

[jordanmontt]

So how de we proceed? Do we merge this PR? @Alokzh @pankaj-bind ?

it looks good to me

[akevalion]

Could we use a singleton for this code?

CTAVLNilNode new

to

CTAVLNilNode uniqueInstance

[pankaj-bind]

@jordanmontt wait I must check concern of @Alokzh and @akevalion

[Alokzh]

Looks good to me Jordan

[pankaj-bind]

Hey @akevalion yes you could use a singleton for CTAVLNilNode to save memory, but it’s not necessary and risks future complexity unless justified by performance needs.

[akevalion]

Looks good for me, I will merge it