The GitHub Actions job "Fory CI" on fory.git/main has succeeded. Run started by GitHub user chaokunyang (triggered by chaokunyang).
Head commit for run: e6ddd2c561af069016dfda1f8358e8a6ef7cb375 / urlyy <[email protected]> refactor(Rust): Refine api name (#2671) ## What does this PR do? 1. Use `read/write_xxx` style APIs for Buffer methods to align with Java API naming. 2. Add `fory_` prefix to `Serializer` and `StructSerializer` trait methods, to avoid name conflict in user struct when it implement other trait with same method name. 3. Organize the APIs on the trait with hierarchical naming `fory_read`,`fory_read_type_info`,`fory_read_data`. The same applies to the write API. Make them distinct from `serialize`/`deserialize` methods of `Fory`. ## Related issues - #2658 - #2672 ## Does this PR introduce any user-facing change? 1. If users want to call fory_methods on user-defined struct instance, they need to use methods whose prefix is `fory_`. 2. User now can customize Serializer without `derive Fory`: ```rust #[test] fn test_use() { use fory_core::fory::{read, write}; #[derive(Debug, PartialEq, Default)] struct Item { f1: i32, f2: i8, } impl Serializer for Item { fn fory_write_data(&self, context: &mut WriteContext, is_field: bool) { write(&self.f1, context, is_field); } fn fory_read_data(context: &mut ReadContext, is_field: bool) -> Result<Self, Error> { Ok(Self { f1: read(context, is_field)?, f2: 0, }) } } let mut fory = Fory::default().mode(Compatible).xlang(true); fory.register_serializer::<Item>(100); let item = Item { f1: 1, f2: 2 }; let bytes = fory.serialize(&item); let new_item: Item = fory.deserialize(&bytes).unwrap(); assert_eq!(new_item.f1, item.f1); assert_eq!(new_item.f2, 0); } ``` Report URL: https://github.com/apache/fory/actions/runs/18112740999 With regards, GitHub Actions via GitBox --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
