The goal is to be able to write reusable components that can be used to compose a contract. For example, FT (NEP-141), Account Storage (NEP-145), etc. The rusty way of doing this is to leverage auto-traits, i.e., blanket trait implementations.
Naturally, you don't want to pull in all auto-traits, the trait implementations to pull in should be explicitly defined. I imagine something like this:
The goal is to be able to write reusable components that can be used to compose a contract. For example, FT (NEP-141), Account Storage (NEP-145), etc. The rusty way of doing this is to leverage auto-traits, i.e., blanket trait implementations.
trait HasKeyValueStore
{ fn get_key_value_store(&self) -> &dyn KeyValueStore; fn get_mut_key_value_store(&mut self) -> &mut dyn KeyValueStore; }
impl KeyValueStore for T
where
T: HasKeyValueStore,
{
fn get(&self, key: U128) -> Option
{ self.get_key_value_store().get(key) }
fn set(&mut self, key: U128, value: U128)
{ self.get_mut_key_value_store().set(key, value); }
}
type Data = Object<u128, u128>;
[derive(Default)]
struct KeyValueStoreService;
impl KeyValueStore for KeyValueStoreService { fn get(&self, key: U128) -> Option
{ Data::load(&key.0) .unwrap() .map(|object| (*object.value()).into()) }
fn set(&mut self, key: U128, value: U128)
{ Data::new(key.0, value.0).save() }
}
KeyValueStore
trait by implementing theHasKeyValueStore
by wiring in the KeyValueStoreServiceKeyValueStore
implementation is not bound bynear_bindgen
The work around is to implement the trait directly and delegate manually:
Naturally, you don't want to pull in all auto-traits, the trait implementations to pull in should be explicitly defined. I imagine something like this:
KeyValueStore
andFungibleToken
trait functions would be boundnear_bindgen
would need to also support marker annotations on the trait, e.g., something likeset
is marked as payablenear_bindgen_trait
would be a new marker attribute