[pag]

The Solidity language is deceptively low level, which partially stems from implementation details related to how the solc compiler chooses to implement language features.

Developers coming to Solidity from a language like Javascript or Python expect names in objects (~Contracts) to be significant determinants in terms of where the data associated with those names are stored. This is due to Javascript objects basically being dictionaries.

I think this problem could have been avoided early on if the storage locations of contract variables were derived from keccak256 hashes of their names. This type of implementation decision, though, would likely require disallowing shadowing of contract variable names in inheritance hierarchies (something I think is a good idea).

If you're not familiar how the solc compiler compilers Solidity to EVM, then using a keccak256 to determine where in persistent storage a value is placed might seem kind of crazy. In fact, this is par for the course. For example, solc implements Solidity key-value mappings by hashing the key along with some other stuff, and then writes the value into memory. This means that mapped values are spready out wildly through the persistent store -- so why not do this for variables?

[jacobush]

Very diplomatic. I'd say tire fire.