PengZheng commented on PR #727:
URL: https://github.com/apache/celix/pull/727#issuecomment-1954213705
> @PengZheng : I believe a more effective solution would be to divide the
array list (and potentially, in the future, the long/string hash map) into
multiple unique array list types based on the element type. The current design
of the array list and hash map does not support entries of different types,
unlike properties. Therefore, in my opinion, it is more streamlined (albeit
requiring additional implementation work) to have distinct array list types for
each element type.
>
> I was considering an approach like this:
>
> ```c
> // Headers (separate header file for each array list type)
> typedef struct celix_ptr_array_list celix_ptr_array_list_t; // Allows
custom types including a custom copy callback
> typedef struct celix_string_array_list celix_string_array_list_t;
> typedef struct celix_long_array_list celix_long_array_list_t;
> typedef struct celix_double_array_list celix_double_array_list_t;
> typedef struct celix_bool_array_list celix_bool_array_list_t;
> typedef struct celix_version_array_list celix_version_array_list_t;
>
> void* celix_ptrArrayList_get(celix_ptr_array_list_t* list, int index);
> const char* celix_stringArrayList_get(celix_string_array_list_t* list, int
index);
> long celix_longArrayList_get(celix_long_array_list_t* list, int index);
> double celix_doubleArrayList_get(celix_double_array_list_t* list, int
index);
> bool celix_boolArrayList_get(celix_bool_array_list_t* list, int index);
> const celix_version_t*
celix_versionArrayList_get(celix_version_array_list_t* list, int index);
>
> // Etc. for set, size, sort...
>
> // C source
> typedef struct {
> ....
> } celix_generic_array_list_t; //<-- current array list
>
> struct celix_ptr_array_list {
> celix_generic_array_list_t* list;
> };
>
> struct celix_string_array_list {
> celix_generic_array_list_t* list;
> };
>
> // Etc.
> ```
>
> A potential temporary solution to avoid extensive refactoring in the same
pull request is to also introduce macros that leverage the C11 _Generic:
>
> ```c
> #define celix_arrayList_get(ListT, index) _Generic((ListT), \
> celix_ptr_array_list_t*: celix_ptrArrayList_get, \
> celix_string_array_list_t*: celix_stringArrayList_get, \
> )(ListT, index)
>
> // Etc. for set, size, sort...
> ```
>
> If we upgrade from `-std=gnu99` to `-std=c11`, we could keep the
`_Generic` approach. However, I'm uncertain if this might be too confusing for
users (C has no overloading, but with `_Generic` it sort-of does).
>
> WDYT?
The original intention of introducing element type is to hide them from
`celix_properties` so that:
* Add only one type to celix_properties, i.e. ArrayList
* Add only four (or more?) methods
setArrayList/assignArrayList/getArrayList/getAsArrayList
* Move element type information into celix_array_list, so that we can have
the right copy operation for them.
So that implies run-time polymorphism rather than compile-time polymorphism,
right?
What will `celix_properties` be like with proposed design?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
