JS / TS 1.9.0

This release has been influenced a bit by C# in the possible values. But also, it continues the Kotlin good practice with no params / varargs arguments.

The majority of the changes is about the LazyGenericCollectionHolder, the CollectionHandler and CollectionIterator.

Another change is about the duplication handling. There is now different methods hasDuplicate, containsDuplicate and includesDuplicate. This is to enable different implementation based on values that are different.

Few plans in the future are to add other remaining javascript ReadonlyArray methods like flat, findIndex (as an alias), findLastIndex (as an alias), reduce, reduceLeft, reduceRight. It is also to add a mutable collection. The addition with no duplicate values (like Set) is also in mind.

It does also properly handle iterator from end-to-start right away. There will no longer be the need to go to the end and then go back. With that, there is also a way to reset the iterator without the needs to create a new instance.

Breaking changes

Also, the has/includes/contains (and other variants) methods will handle non-variadic arguments. It will be supported in the version 1.9, but will not in 1.10

Now the CollectionIterator should give null whenever the indexes are not initialized or outside of the boundary of its collection.
This will change the approach, but hopefully give a better representation of where the iterator is at.

Changes in the CollectionHolder

There is the addition / change to the "has" methods and the "join" methods.

• The EmptyCollectionHolder now handle the values to the most generic value (unknown if it is ignored)
• The EmptyCollectionHolder now handle the hasAll / includesAll / containsAll for empty values as true instead of always false (like it was previously)
• new joinToString
• change to join to be an alias of joinToString (for the moment)
• change to the has / includes / contains to handle only one variable, the remaining arguments will not be supported in 1.10
• change to hasOne (this will be replaced with only non-variadic parameter in 1.10)
• change to includesOne (this will be replaced with only non-variadic parameter in 1.10)
• chante to containsOne (this will be replaced with only non-variadic parameter in 1.10)
• change to hasAll (this will be replaced with only non-variadic parameter in 1.10)
• change to includesAll (this will be replaced with only non-variadic parameter in 1.10)
• change to containsAll (this will be replaced with only non-variadic parameter in 1.10)

Changes in the CollectionHolder extension methods

With some changes, comes new paths toward the values received. Most notably, the hasOne, hasAll and has.

• Fix of incoherence for sliceByCollectionHolderWithSet → sliceWithSetByCollectionHolder. It should have a name similar to all of the other slice methods
• New has extension method (for a single value)
• Update to the hasOne to have different variation based on the value hasOne.withArray, hasOne.withCollectionHolder, hasOne.withCollectionIterator, hasOne.withIterable, hasOne.withMinimalistCollectionHolder, hasOne.withSet
• Update to the hasAll to have different variation based on the value hasAll.withArray, hasAll.withCollectionHolder, hasAll.withCollectionIterator, hasAll.withIterable, hasAll.withMinimalistCollectionHolder, hasAll.withSet
• Deprecation of join (joinToString should be used instead)

Changes in the CollectionConstants

The collection constant was at first made to contains only the values that should not change, but it grew larger than intended. With the progression of other languages, it will have changes made in the next version.

One of that is the changing of the getter methods EVERY_***_METHODS to only be ***_MEMBERS.

Changes in the CollectionIterator

The iterator has the purpose to give a way to loop through a collection, but also to give its internal state without the validation of "magic numbers". Thus, the usage of null is now present on the currentIndex, nextIndex and previousIndex. Meaning that instead of validating nextIndex < size or even previousIndex > -1, it should be toward nullability.

Also, now, it properly handle backward value from the start instead of getting to the end and then go backward.

And the methods should all be independent (or close to it) to each other. It will be more complicated under the scene, but the result is about the same.

The changes can be summed to:

• new method reset
• change to index to use a NullOrNumber instead (it should be null instead of 0 if it did not even start)
• new getter method currentIndex (it should replace the normal usage of index, but not remove it)
• change to nextIndex to use a NullOrNumber (it will give null instead of the size if it is at the end)
• change to previousIndex to use a NullOrNumber (it will give null instead of -1 if it is at the start)
• change on EmptyCollectionIterator.index to return null instead of 0
• change on EmptyCollectionIterator.nextIndex to return null instead of 0
• change on EmptyCollectionIterator.previousIndex to return null instead of 0
• support of variadic parameters to anything on every EmptyCollectionIterator methods compatible

There will be upcoming changes in the next version. Those methods are currently protected under the GenericCollectionIterator

• new method _isEmpty
• new method _hasOnly1Element
• change from _index to _currentIndex
• new method _firstIndex
• new method _isFirstIndexInitialized
• new method _lastIndex
• new method _isLastIndexInitialized
• new method _isPreviousIndexInitialized
• new method _isNextIndexInitialized

Changes in the CollectionHandler

All of the handlers have a beta annotated to them since they are only used in the LazyGenericCollectionHolder and more tests needs to be done on them.

Only the AbstractCollectionHandler(by1Value|by2Values) and the CollectionHandlerByArray(of1|of2) because they are used and tested.

One change is present about the handlers and it is the fact that each handlers (excluding the iterator) have 3 variants. For a size of 1, 2 and unspecified. This has the effect to optimize small tables and have a generic implementation for larger tables.

Another change is to include a way to see if there is duplicate values within the handlers.

• change to the CollectionHandlerByArrayOf1 inheritance from CollectionHandlerByArray to AbstractCollectionHandlerBy1Value
• new CollectionHandlerByArrayOf2
• change to the CollectionHandlerBySetOf1 inheritance from CollectionHandlerBySet to AbstractCollectionHandlerBy1Value
• new CollectionHandlerBySetOf2
• new CollectionHandlerByIterableWithSizeOf1
• new CollectionHandlerByIterableWithSizeOf2
• new CollectionHandlerByMinimalistCollectionHolderOf1
• new CollectionHandlerByMinimalistCollectionHolderOf2
• new CollectionHandlerByCollectionHolderOf1
• new CollectionHandlerByCollectionHolderOf2
• new CollectionHandlerByCollectionIterator
• new CollectionHandlerByCollectionIteratorOf1
• new CollectionHandlerByCollectionIteratorOf2

The handler values have now a proper implementation. It varies from an impossible index, not a specific index, over the edges of number, an empty or a valid value.
Of course, the ValueHolder has been relocated to the folder handler/value to have a more fitting location.

Changes in the utility types

In order to keep the code simpler to read, some types has been added, while other removed due to duplication

• New PossibleArraySetCollectionHolderOrIterable to remove large alias readonly T[] | ReadonlySet<T> | CollectionHolder<T> | MinimalistCollectionHolder<T> | CollectionIterator<T> | Iterator<T>
• Removal of Nullable, use the type in @joookiwi/type
• Removal of NullOr, use the type in @joookiwi/type
• Removal of UndefinedOr, use the type in @joookiwi/type
• Removal of NumberOrNumberInString, use the TemplateOrNumber in @joookiwi/type
• Removal of PossibleNumeric, use the NumericOrObject in @joookiwi/type

Other changes

• Upgrade of the lazy dependency from 1.4.0 to 1.5.0