Update Meta Standard to include snake case method names as a standard

[ilblackdragon]

We need to define which naming convention standards suppose to follow:

• Snake case for Rust
• Camel case for AS/TS/JS & Ethereum

Specifically, it's important because frontend is mostly in JS and expectation is that all calling of arguments will be in Camel Case. While Rust is enforcing Snake case.

I think we can lean toward Camel case to maintain compatibility with frontend and Ethereum standards and add whatever flags required in Rust to enforce that instead of Snake case. This though requires among other things adjusting our Fungible Token standard.

Thoughts?

[maxzaver]

We can do both. Every contract method can be exposed in both camel and snake case, it is a tiny modification to near-sdk-rs and will have a negligible effect on contract size.

[maxzaver]

Specifically, currently for each impl method my_method(&self, args..) near-sdk-rs generates method my_method(). It should generate three methods: _my_method(), my_method() { _my_method() }, and myMethod() { _my_method() }. It already exports inflector for converting between snake case and camel case https://github.com/near/near-sdk-rs/blob/master/near-sdk-core/Cargo.toml#L18 .

[maxzaver]

Closing in favor of https://github.com/near/near-sdk-rs/issues/209

[ilblackdragon]

We still need the guideline for standards. The standards is what people will be using when composing contracts and using them from frontend.

E.g. when writing code like this should work with ANY contract in the future: https://github.com/ilblackdragon/balancer-near/blob/master/balancer-pool/src/btoken.rs#L127

[maxzaver]

This issue does not explain why we need standard, if near-sdk-* can expose all contract methods in both camel and snake case.

For example. Alice writes Rust contract

#[near_bindgen]
impl AliceContract {
  pub fn alice_method() {
  }
}

Bob writes AS contract:

export function bobMethod(): void {
}

Then anyone can call Alice's contract from near-api-js as contract.aliceMethod or contract.alice_method. Similarly anyone can call Bob's contract from near-api-js as contract.bobMethod or contract.bob_method. Similarly, anyone can call them by snake or camel case from other contracts.

How standardization or guidelines would be useful here?

[robert-zaremba]

IMHO, generating additional names only create confusions. I like styles and naming conventions. I don't see much reason of duplicating names through SDK. Especially, that it will incure extra gas cost.

[ilblackdragon]

This issue does not explain why we need standard

We need standard because we have standards - https://nomicon.io/Standards/Tokens/FungibleToken.html#reference-level-explanation. And these standards have naming convention that both contracts and off-chain code will be using. We definitely should not list two sets of names in those standards (and if we do ===> that's a standard too, and AS, Go, Haskell, whatever other language contracts must implement them as well).

[ilblackdragon]

This is more critical then before with 141 finalization. @evgenykuzyakov @robert-zaremba Are we committing that all standards should be using snake case?

[zahhar]

Both approaches (duplicate method names or stick to single style) look wrong for me.

How about removing the root cause of a problem by sticking to single-word names for common methods, and leaving complete freedom for user-defined methods?

Here is what I mean: in both Rust, AS or what-so-ever-language-NEAR-is-gonna-support-in-the-future we can write all public methods required by standard this way:

export function transfer() and pub fn transfer() that will be called using any kind of SDK as contract.transfer

It is a matter of finding enough single-word names for a handful of mandatory methods.

And when it comes to private methods, or to contract-specific methods, there should be no limit imposed how to name things. Anyhow developer working with contract must familiarise himself with its interfaces.

[oysterpack]

sticking to single-word names for common methods

That simply won't work because all contract functions are effectively scoped globally. NEAR standard API interfaces must be namespaced to avoid collisions.

The problem is that the NEAR library ecosystem is pretty much non-existent at this phase of the lifecycle. Think of defining the JSON RPC API just like defining any HTTP API. Regardless which route you go, i.e., REST, GraphQL, etc, the HTTP API is too low level to work with. Higher level client libraries, frameworks, and tooling is lacking in the NEAR ecosystem. This is what we need to make developers productive and accelerate time to market.

I have said this before multiple times on multiple other posts ... and I'll keep saying it until the idea sticks ...

As for NEAR standard APIs .. the bottom line is

"Talk is cheap. Show me the code" - Linus Torvalds

I would argue that at a minimum, the NEAR DEV team is responsible for delivering on the high level libraries for every NEAR standard API by any means necessary. If the NEAR DEV team does not have the personnel and time to develop them internally, then I propose that the NEAR DEV team tap into the NEAR developer community through bounties, guilds, and partners.

It's a chicken and egg problem ...

[evgenykuzyakov]

Let's just with snake_case since we're going for mostly Rust. near-api-js can expose methods in camelCase while calling contract in snake_case.

[robert-zaremba]

This is more critical then before with 141 finalization. @evgenykuzyakov @robert-zaremba Are we committing that all standards should be using snake case?

Yes. Having a single style for standards has a benefit in readability. As @evgenykuzyakov - for whatever reasons, libraries can do the translation if needed.

[ilblackdragon]

Let's publish this as part of meta-standard here in NEPs. Also this should be followed up by work in near-sdk-as to export the snake case function names: https://github.com/near/near-sdk-as/issues/430

FYI @mikedotexe

I do want to mention that camelCase is actually more compact (less bytes on chain :D) and leave this topic silent forever.