pandalee99 commented on issue #2595:
URL: https://github.com/apache/fory/issues/2595#issuecomment-3271333382

   > Some things that came in my head, which needs be done:
   > 
   > * [ ]  Make arrow integration optional, not all users needs this 
integration[ ]  Make fory cpp reflection system decoupled from arrow type 
system, [@PragmaTwice](https://github.com/PragmaTwice) added the first version 
of cpp reflection implementation, I'm not sure whether he still has time for 
this.[ ]  Add cmake build support, since most cpp users use cmake for build[ ]  
Add type resolver for object graph in c++[ ]  Add reference resolver for object 
graph in c++[ ]  Build a macro/template based compile-codegen system for 
fory-cpp. Note that fory cpp use c++ 17, and we won't use c++ 20. Build 
compile-reflection systemm may take some efforts.[ ]  Support serialization for 
basic types[ ]   Support serialization for nested collection/map/set types 
using compile-codegen module[ ]   Support serialization for struct and nested 
struct using compile-codegen module[ ]   Support type meta encoding for schema 
evolution[ ]   Support schema evolution serialization based on type meta, we 
need
  to generate two version of deserializaion code at compile-time[ ]  Support 
circular and shared reference such as shared_ptr, weak_ptr, unique_ptr
   
   Yes, these are all very good ideas!
   All these are functions that need to be gradually implemented in the future. 
However, I have another idea. In fact, pyfory can share a code logic with the 
cpp module and then call it using methods such as nanobind. This can further 
upgrade the old cython system and update the API at the same time.
   Because I think very few people would directly call the c++ serializer. Such 
users seem not to be too many.
   However, pyfory calls the cpp module at the bottom layer. I'm not sure if 
this compatibility is sufficient?
   And pyfory still has greater potential for development, such as being 
integrated into ray? Or it can be used in various scientific computations, 
which are all very good ideas!
   Also, what kind of thinking would the fory cpp reflection system have?
   Will fory, in the future, follow arrow's example and implement inter-memory 
sharing?


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to