You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As the stdlib grows, patterns of organization and usage are beginning to emerge.
Currently the library is primarily structured around what things are rather than how they are used.
I propose we switch to a more developer-focused API, where we group things together that are typically used in the same context.
Below is an example of how we could potentially add contracts.sw& calls.sw modules following this new organizing principle:
//!Functionality that is either logically related to or only usable in the context of contracts
library contracts;
// currently in context.sw
pub fn balance_of(...) -> u64;
pub fn this_balance() -> u64
// currently in call_frames.sw
pub fn contract_id() -> ContractId
// currently in token.sw
pub fn mint_to(...)
pub fn mint_to_contract(...)
pub fn mint_to_address(...)
pub fn mint(...)
pub fn burn(...)
pub fn transfer(...)
pub fn force_transfer_to_contract(...)
pub fn transfer_to_address(...)
//!Functionality that is either logically related to or usable only in the context of contract calls
library calls;
/**
NOTE: Solidity exposes these as things like `msg.sender`, `msg.amount`, `msg.data`.
There may be some confusion with our `message` types (`Input::Message` & `Output::Message`) if we
continue to follow this naming precedent. Similar to the proposed `Contract` type with methods on it,
we could introduce a `Call` type with methods, i.e:
let amount = call.amount();
let sender = call.sender();
etc...
*/
// currently in call_frames.sw
pub fn msg_asset_id() -> ContractId
// currently in context.sw
pub fn msg_amount() -> u64;
pub fn gas() -> u64
// currently in auth.sw
pub fn msg_sender() -> Result<Identity, AuthError>
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
As the stdlib grows, patterns of organization and usage are beginning to emerge.
Currently the library is primarily structured around what things are rather than how they are used.
I propose we switch to a more developer-focused API, where we group things together that are typically used in the same context.
Below is an example of how we could potentially add
contracts.sw
&calls.sw
modules following this new organizing principle:Beta Was this translation helpful? Give feedback.
All reactions