Remove unnecessary read only methods

[mijoco-btc]

According to Clarity WG we should favour map-get / var-get api calls over read-only functions which return the same information as the contract footprints are lighter.

[whoabuddy]

I agree with this in general but do see the value in creating aggregated read-only functions that expose a set of variables.

This serves as an external lookup for UIs and other contracts that cannot read these values directly.

For example, if you have:

https://github.com/radicleart/bitcoin-dao/blob/7503978832ad26aec3c21c75479ea3a8a73067c4/contracts/extensions/bde020-resource-manager.clar#L41-L47

Then instead of a one-off read only function exposing the variable like this:

https://github.com/radicleart/bitcoin-dao/blob/7503978832ad26aec3c21c75479ea3a8a73067c4/contracts/extensions/bde020-resource-manager.clar#L123-L126

We could return a single tuple instead:

(define-read-only (get-contract-stats)
  {
    totalUsers: (var-get userCount),
    totalResources: (var-get resourceCount),
    totalInvoices: (var-get invoiceCount),
    totalRevenue: (var-get totalRevenue),
  }
)

Before I'm fully convinced though I'd like to do a cost comparison.

• while this makes the contract length shorter, how much are we saving by doing so? Is it a significant amount?
• if using the read-only function from another contract, how much more expensive is it to read the tuple and get the needed values versus calling the individual read-only functions when needed?

Also, looking at the docs for the API, it looks like we can query a map inside a contract but can you read a data-var?

[mijoco-btc]

Agree with all these points.

You can get a data var through API but it hasn't been documented just raised this here

/v2/data_var/${contractAddress}/${contractName}/${dataVarName}

Contracts can also directly read data-vars from other contracts (according to chatgpt - never tried this myself);

(contract-call? .SP2JNWX37AJFEMZ8JD4X9C7JK3YSQ6QP7K05F7Z8.get-my-var))

Agree comparison of the costs is important.

[whoabuddy]

I suspect that won't work but we should test, would be another reason to fine tune a model more on stacks/clarity!