LouisLou2 commented on code in PR #2112:
URL: https://github.com/apache/fury/pull/2112#discussion_r2008758192
##########
dart/README.md:
##########
@@ -0,0 +1,218 @@
+# Fury Dart
+
+## Overview
+
+This PR adds Dart language support to Apache Fury, implementing a
comprehensive serialization solution for Dart and Flutter applications. Fury
Dart consists of approximately 15,000 lines of code and provides an efficient
serialization mechanism that works within Flutter's reflection limitations.
+
+## Implementation Approach
+
+Dart supports reflection, but Flutter explicitly prohibits it. To address this
constraint, Fury Dart uses a combination of:
+
+1. Core serialization/deserialization logic
+2. Static code generation for type handling
+
+This approach ensures compatibility with Flutter while maintaining the
performance and flexibility expected from Fury.
+
+## Features
+
+- XLANG mode support for cross-language serialization
+- Reference tracking for handling object graphs
+- Support for primitive types, collections, and custom classes
+- Serializer registration system
+- Code generation for class and enum serialization
+- Support for nested collections with automatic generic type conversion
+- Custom serializer registration
+- Support for using ByteWriter/ByteReader as serialization sources
+
+## Usage Examples
+
+### Basic Class Serialization
+
+```dart
+import 'package:fury_core/fury_core.dart';
+
+part 'some_class.g.dart';
+
+@furyClass
+class SomeClass with _$SomeClassFury {
+ late int id;
+ late String name;
+ late Map<String, double> map;
+
+ SomeClass(this.id, this.name, this.map);
+
+ SomeClass.noArgs();
+}
+```
+
+After annotating your class with `@furyClass`, run:
+
+```bash
+dart run build_runner build
+```
+
+This generates the necessary code in `some_class.g.dart` and creates the
`_$SomeClassFury` mixin.
+
+### Serializing and Deserializing
+
+```dart
+Fury fury = Fury(
+ xlangMode: true,
+ refTracking: true,
+);
+fury.register($SomeClass, "example.SomeClass");
+SomeClass obj = SomeClass(1, 'SomeClass', {'a': 1.0});
+
+// Serialize
+Uint8List bytes = fury.toFury(obj);
+
+// Deserialize
+obj = fury.fromFury(bytes) as SomeClass;
+```
+
+### Enum Serialization
+
+```dart
+import 'package:fury_core/fury_core.dart';
+
+part 'enum_foo.g.dart';
+
+@furyEnum
+enum EnumFoo {
+ A,
+ B
+}
+```
+
+Registration is similar to classes:
+
+```dart
+fury.register($EnumFoo, "example.EnumFoo");
+```
+
+## Type Support
+
+Fury Dart currently supports the following type mappings in XLANG mode:
+
+| Fury Type | Dart Type
|
+|----------------------------|------------------------------------------------|
+| bool | bool
|
+| int8 | fury.Int8
|
+| int16 | fury.Int16
|
+| int32 | fury.Int32
|
+| var_int32 | fury.Int32
|
+| int64 | int
|
+| var_int64 | int
|
+| sli_int64 | int
|
+| float32 | fury.Float32
|
+| float64 | double
|
+| string | String
|
+| enum | Enum
|
+| named_enum | Enum
|
+| named_struct | class
|
+| list | List
|
+| set | Set (LinkedHashSet, HashSet, SplayTreeSet)
|
+| map | Map (LinkedHashMap, HashMap, SplayTreeMap)
|
+| timestamp | fury.TimeStamp
|
+| local_date | fury.LocalDate
|
+| binary | Uint8List
|
+| bool_array | BoolList
|
+| int8_array | Int8List
|
+| int16_array | Int16List
|
+| int32_array | Int32List
|
+| int64_array | Int64List
|
+| float32_array | Float32List
|
+| float64_array | Float64List
|
+
+## Project Structure
+
+The implementation is organized into three main components:
+
+1. **SourceGen**: Located at `dart-fury/packages/fury-core/lib/src/code_gen`
+ Handles static code generation for serialization/deserialization.
+
+2. **FuryCore**: Located at `dart-fury/packages/fury-core/lib/src`
Review Comment:
Are you suggesting to change the directory structure to
`dart-fury/lib/fury/core` and `dart-fury/test`? I actually considered this
approach, which would eliminate the need for Dart workspace features and
simplify the structure.
However, my initial intention was to leverage workspaces to completely
isolate the testing environment and simulate real-world usage scenarios,
especially since the package involves complex codegen functionality. That's why
I decided to make the test component a separate workspace, placing it at the
same level as the core component under the packages directory.
I think we can maintain this structure but change the hyphenated names to
snake_case. After reviewing [Pub workspaces (monorepo support)
](https://dart.dev/tools/pub/workspaces,) it seems that even independent
packages should follow standard directory naming conventions using snake_case.
So I believe we should make this change - the outer dart-fury directory should
also be renamed to `dart_fury` or `fury_dart`.
--
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]
