Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create cairoDataTypes for all Cairo Types #1116

Open
tabaktoni opened this issue May 2, 2024 · 10 comments
Open

Create cairoDataTypes for all Cairo Types #1116

tabaktoni opened this issue May 2, 2024 · 10 comments
Assignees
Labels
C2 generally explained task without specification and elaboration. Contains multiple subtasks. Type: feature New feature or request

Comments

@tabaktoni
Copy link
Collaborator

tabaktoni commented May 2, 2024

Feature

I created CairoUint256 Class as an example of how should Cairo types be represented in js.
@PhilippeR26 created CairoUint512 base on the same concept

We should have all Cairo Types represented this way as a Class. It would give the dev flexibility to use any final form of that type he would need for the case. For example, Felt can be represented as hex-string or BigInt or any other supported format. If it is class-based then the class holds value and all export transformations inside itself for any case usage.

What we need:

  • Convert Felt into Class
  • Add all missing CairoTypes (array, Address, tuple, enum, long string....)
  • Create a common interface for this class that each class would use for definition (named maybe: CairoType)

How to Dev

  • Take one type you would like to work on and open PR per one type you adopt

PR should contain:

  • Cairo'X' Class
  • All the tests specifically for that type like CairoUint256
  • Implementation/refactoring of request and response parsers using that class
  • any other codebase possible usages of that class
  • any other test usages of that class
  • It should not break existing tests, we need to stay backward-compatible

Update 1

What's left and the order of development:
u8, u16, u32 (usize), u64, u128, bool, ByteArray (bytes31 aka long string), tuple, struct, Secp256k1Point,
i8, i16, i32, i64, i128, ContractAddress, EthAddress, StorageAddress, ClassHash

serialization_of_Cairo_types

  • Felt should be done first as it is used on all types.
  • Struct, Array, and Tuple should be done last as it would use other types
  • If I forgot some type please mention it.
@tabaktoni tabaktoni added Type: feature New feature or request OnlyDust Open for OnlyDust contributors C2 generally explained task without specification and elaboration. Contains multiple subtasks. labels May 2, 2024
@tabaktoni
Copy link
Collaborator Author

tabaktoni commented May 2, 2024

After Completing this step next step is to make request and response parsers configurable for each type.
So one could configure that his response parser should return CairoTypes class, another can configure that felt should be converted to BigInt, another can say that Felt should be hex-string, and so on...
The default behavior should be backward compatible so the default setup will be as it is now.

This would introduce flexibility in default parsing In addition to Abi-Wan configurability we would have a complete circle for typing system.

@Immanuelolivia1
Copy link

Please can I be assigned to this

@tabaktoni
Copy link
Collaborator Author

tabaktoni commented May 2, 2024

Please can I be assigned to this

You can be assigned to one type you would like to adapt, chose one and it is yours (like Felt or arrays)

@raizo07
Copy link

raizo07 commented May 2, 2024

I'll like to be assigned to work on enums

@Calebux
Copy link

Calebux commented May 2, 2024

I will like to be assigned to work on Arrays

@Immanuelolivia1
Copy link

I will like to work on felts

@tabaktoni
Copy link
Collaborator Author

I'll like to be assigned to work on enums

Just to point out enums are a pretty complex topic, here are the existing dir with the current implementation.
You would need to use this one and refactor/update it to CairoType format, move it to new dir and so on.
There are 3 types of enums: Options, Result and Custom. You can do one or all of that at the same PR as you like

@ivpavici
Copy link
Collaborator

ivpavici commented May 2, 2024

@Calebux @Immanuelolivia1 @raizo07 hi!
We expect high quality and thoroughly tested PR-s! If not we will not review nor merge!

@b0rza
Copy link
Contributor

b0rza commented Jun 1, 2024

@tabaktoni 👋 what's the status of these?

@ivpavici
Copy link
Collaborator

ivpavici commented Jun 3, 2024

@b0rza hi! it's up for the taking :)

@b0rza b0rza mentioned this issue Jun 5, 2024
6 tasks
@ivpavici ivpavici removed the OnlyDust Open for OnlyDust contributors label Sep 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C2 generally explained task without specification and elaboration. Contains multiple subtasks. Type: feature New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants