hashgraph / hashgraph/hedera-sdk-reference

Decide on a convention for language SDKs where a type needs to be deserialized without fore-knowledge

Open
#53 0 comments 0 reactions 2 assignees Claimed by @janaakhterov View on GitHub
swift
Dominant language
HTML
Stars
7
Forks
3
PR merge metrics
No merged PRs in 30d

Description

**Context**

In Java, Go, and JavaScript, we can say `Transaction.fromBytes` or `CustomFee.fromBytes` and the _**actual**_ class that gets returned is a derived type (e.g., `TransferTransaction` or `CustomFixedFee`). This is not possible in Rust or **Swift**.

**Proposal**

Introduce a new data-attached enum type, `AnyX`, that is used when a type hierarchy needs to be deserialized.

Use cases:

- `AnyTransaction` is an `enum` of all transaction types. You may deserialize from bytes (protobuf) or json into this type. You would then match to extract the actual transaction type.
- `AnyQuery`
- `AnyRequest` (Transaction or Query)
- `AnyCustomFee`

**Exceptions**

- `Key` is already a data-attached enum as we need to distinguish between "contract keys" and "delegatable contract keys". Therefore a user can deserialize into `Key`.

**Scope**

This would only be required to affect Rust and Swift. There is little benefit in the others as OOP is more central to the language. It could be added to the others for consistency.

**Alternatives**

- The type hierarchy could be defined in terms of the enumeration instead. In other words, the `Transaction` type would be a `enum` instead of a "base type". This is not ideal because the user would need to match on the type of transaction in order to act on it.

- We could not allow deserialization. This affects some core features so likely not possible.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.