search

ethpm / ethpm-spec

Ethereum Package Manager http://ethpm.github.io/ethpm-spec/
165 stars 30 forks source link

"contract_types" to "contracts" #84

Open fubuloubu opened 6 years ago

fubuloubu commented 6 years ago

Mostly just a semantics thing, why is it "contract_types" instead of something simpler like "contracts"?

Solidity's JSON output puts them into a "contracts" object. Might make for easier compatibility.

pipermerriam commented 6 years ago

Then intent was to differentiate between instances and types. Using the name contracts would be fine, but I think it is more likely to be confused with being the container for deployed contract instances without the suffix.

fubuloubu commented 6 years ago

Why not just do "instances"?

pipermerriam commented 6 years ago

do you mean renaming deployments to instances?

Because they are not strictly a list of contract instances but a mapping of chain URI -> Name -> Instance and so deployments seemed like a more appropriate name.

fubuloubu commented 6 years ago

Yeah, that's definitely not what we'd want to do. Deployments makes more sense.

You are saying contracts might get confused with deployments i.e. the contract instances that have been deployed to the network? I think it's bit semantics, contract_types sounds like there are categories of contracts that exist.

Ultimately, someone who is using an ethpm package should know the difference between a contract and a deployment.

pipermerriam commented 6 years ago

The reason we went with the suffix is that the word contract is overloaded.


contract Token {
   ...
}

So we chose to add a suffix. I think removing the suffix is worse than the potential for people to confuse the term types to mean "categories". I'd be good entertaining alternate suffixes, or ways to deliniate the difference between a contract as a deployed entity, and a contract as defined in source code. But just using the term *contracts` feels overloaded to me.

fubuloubu commented 6 years ago

Fair enough, that is a valid point. Maybe compiled_contracts?

In one of my projects, I was creating a contracts.min.json that removed all of the contracts that solidity outputs and only kept the ones my platform was exposing for endpoint use. This made my front end code a bit smaller when it was downloading that as an asset along with the compiled front end code. Would be interesting if compiled_contracts were the subset that the package was exposing for use, whereas the source might define more intermediate and/or testing contracts.