Closed srghma closed 1 year ago
My opinion is that the types as they stand now are way simpler to maintain than something like this — types like BigNumberFromLowercaseString are unnecessarily specific, BigNumber is fine as it is. What is the real advantage to introducing this other than potentially debugging what is already there, which we currently have no evidence is wrong?
Also how would you actually generate valid purescript types/modules
Also how would you actually generate valid purescript types/modules
here is a better proposal
module EthereumExecutionApi.Address where
-- hex encoded address
newtype Address = Address String
addressRegex = unsafeRegex "^0x[0-9,a-f,A-F]{40}$" noFlags
mkAddress :: String -> Maybe Address
mkAddress string =
if test addressRegex string
then Just $ Address string
else Nothing
-- or to use https://github.com/garyb/purescript-codec-argonaut
-- which is actually better, though one have to write codecs by hand (no deriving)
instance DecodeJson Address
...
-- or
codecAddress :: JsonCodec Address
codecAddress = ...
from https://github.com/ethereum/execution-apis/blob/main/src/schemas/block.json#L2-L33
module EthereumExecutionApi.Block where
-- Block object
-- NOTE: "oneOf" becomes a parameter to Block
type Block transactions =
{ ....
, transactions :: transactions
, miner :: Address
, uncles :: Array Hash32
}
blockCodec :: forall . JsonCodec transactions -> JsonCodec (Block transactions)
blockCodec transactionsCodec = ...
What is the real advantage to introducing this other than potentially debugging what is already there
just an idea
just an idea for future
as per https://playground.open-rpc.org/?schemaUrl=https://raw.githubusercontent.com/ethereum/eth1.0-apis/assembled-spec/openrpc.json
the
Block
frometh_getBlockByHash
should be notbut