Create cairoDataTypes for all Cairo Types

[tabaktoni]

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]

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.

[0xOlivanode]

Please can I be assigned to this

[tabaktoni]

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]

I'll like to be assigned to work on enums

[Calebux]

I will like to be assigned to work on Arrays

[0xOlivanode]

I will like to work on felts

[tabaktoni]

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]

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

[b0rza]

@tabaktoni 👋 what's the status of these?

[ivpavici]

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