Auto-implement getter methods for pub fields on the contract struct

[frol]

Initially, I thought it would be a great idea, but after I wrote it down, I believe it is going to create more problems than it solves.

---

Looking at whitelist contract, I wish there are getters to the public methods of the struct. Implementing those manually might be routine, so I am thinking if some derive magic should be added, so all pub fields would have getters implemented automagically, and with proper pagination.

Just to illustrate, I feel this code:

#[near_bindgen]
#[derive(BorshDeserialize, BorshSerialize)]
pub struct WhitelistContract {
    /// The account ID of the NEAR Foundation. It allows to whitelist new staking pool accounts.
    /// It also allows to whitelist new Staking Pool Factories, which can whitelist staking pools.
    pub foundation_account_id: AccountId,

    /// The whitelisted account IDs of approved staking pool contracts.
    pub whitelist: UnorderedSet<AccountId>,

    /// The whitelist of staking pool factories. Any account from this list can whitelist staking
    /// pools.
    pub factory_whitelist: UnorderedSet<AccountId>,
}

would be expanded to have the following implementations:

#[near_bindgen]
impl WhitelistContract {
    pub fn get_foundation_account_id(&self) -> &AccountId {
        &self.foundation_account_id
    }

    pub fn get_whitelist(&self, from_index: usize, limit: usize) -> HashSet<AccountId> {
        self.whitelist.iter().skip(from_index).limit(limit).collect()
    }

    ...
}

The downside is that it might be too magical. Explicit is better than implicit vs ergonomic balance needs to be adjusted. Also, different structs will need to be handled differently, potentially, re-collecting the lists, and introduce pagination, so it only makes things even more magical.

[willemneal]

Perhaps then a new derive macro?

[frol]

@willemneal I cannot think of a way to make DevX predictable here given that collections require special handling, so I will only keep this issue open for visibility, but I don't expect anyone to take it before we come up with a better design for it (if at all).