PengZheng commented on code in PR #782:
URL: https://github.com/apache/celix/pull/782#discussion_r1922965827
##########
libs/dfi/README.md:
##########
@@ -71,9 +71,9 @@ The data types supported by the interface description include:
*Type schema*:
- |**Identifier**|B |D |F |I |J |S |V |Z
|b | i | j | s |P | t |N |
-
|---------|---|------|-----|-------|-------|-------|----|--------------|-----|--------|--------|--------|------|------------------|---|
-
|**Types**|char|double|float|int32_t|int64_t|int16_t|void|boolean(uint8)|uchar|uint32_t|uint64_t|uint16_t|void
*| char *(C string) |int|
+ |**Identifier**|B |D |F |I |J |S |V |Z
|b | i | j | s |P | t |N | p
| a |
Review Comment:
> A remote call is less trustworthy, so IMO crashing (assert fail) is then
not an option.
I totally agree.
> To be honest, I am still unsure if the current array list implementation
is the correct approach. Another option could be to really split up the public
array list API in a long, double, string, pointer, boolean, version array. So
something like: celix_long_array_list_t with functions like
celix_longArrayList_get, etc.
Imagine that we are dealing with json rather than array list or properties,
there are at least two options:
1. Let the service implementation perform type checking manually, calling
`json_is_array` etc.
2. Delegate type checking to the framework via json schema, which is
essentially the same as type annotation approach. Then it will be OK to add
various type assertions to the service implementation (for documentation
purpose), which may be remote or local.
Both should work.
--
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
