With the addition of multiplatform support, I encountered a name clash and, as a result, confusion in understanding.
As an example, there is a multik-native module, its artifacts will be as follows:
multik-native-jvm
multik-native-native
multik-native-macosX64
multik-native-macosArm64
multik-native-iosArm64
multik-native-linuxX64
multik-native-mingwX64
This naming makes confusion.
Therefore, it is necessary to rename the modules in accordance with their purpose and multiplatform.
Since renaming modules breaks compatibility and makes publishing difficult, I'm posting this as a proposal.
multik-api
multik-api doesn't have problems with multiplatform naming conventions, but the name doesn't reflect the essence of the module. The module itself consists of a data structure (ndarray), simple and iterative operations on ndarrays, and interfaces for mathematics, linear algebra, and statistics. In that case, I think it's correct to call this module multik-core, since this describes the essence well.
multik-jvm
There is confusion in the names multik-jvm-jvm and multik-jvm-native here. This module implements interfaces from multik-api (multik-core) in pure Kotlin without native code. Then it can be called as multik-pure-kotlin. But in this case, this name is not well in my opinion. I would be glad if you suggest other variants.
multik-native
Obviously there is confusion with native for jvm. This module implements interfaces from multik-api (multik-core) using the OpenBLAS library and partially cpp code. One obvious option was to name this module as multik-openblas, but other native libraries may be added in the future and then this name will not be correct.
multik-default
This module combines multik-jvm and multik-native implementations. This name works well for users who do not want to understand the intricacies of the library. Nevertheless, in terms of Kotlin, it is more correct to name this module as multik-common, but you can leave the old name as well.
I will be glad if you share your vision and experience of using the library in order to clearly understand how to name different modules.
With the addition of multiplatform support, I encountered a name clash and, as a result, confusion in understanding. As an example, there is a multik-native module, its artifacts will be as follows:
This naming makes confusion.
Therefore, it is necessary to rename the modules in accordance with their purpose and multiplatform. Since renaming modules breaks compatibility and makes publishing difficult, I'm posting this as a proposal.
multik-api
multik-api
doesn't have problems with multiplatform naming conventions, but the name doesn't reflect the essence of the module. The module itself consists of a data structure (ndarray), simple and iterative operations on ndarrays, and interfaces for mathematics, linear algebra, and statistics. In that case, I think it's correct to call this modulemultik-core
, since this describes the essence well.multik-jvm
There is confusion in the names
multik-jvm-jvm
andmultik-jvm-native
here. This module implements interfaces frommultik-api
(multik-core
) in pure Kotlin without native code. Then it can be called asmultik-pure-kotlin
. But in this case, this name is not well in my opinion. I would be glad if you suggest other variants.multik-native
Obviously there is confusion with native for jvm. This module implements interfaces from
multik-api
(multik-core
) using the OpenBLAS library and partially cpp code. One obvious option was to name this module asmultik-openblas
, but other native libraries may be added in the future and then this name will not be correct.multik-default
This module combines
multik-jvm
andmultik-native
implementations. This name works well for users who do not want to understand the intricacies of the library. Nevertheless, in terms of Kotlin, it is more correct to name this module as multik-common, but you can leave the old name as well.I will be glad if you share your vision and experience of using the library in order to clearly understand how to name different modules.