Closed fulldecent closed 5 years ago
How about this construction?
Enum types (i.e. the constants inside an
enum
declaration) are static instances and Aion assigns static instances unique values forhashCode
. This depends on a contract not having more than Integer.MAX_VALUE, which is already impossible due to energy limits. Java definesEnum.hashCode
as a final method and therefore it cannot be overridden. (Source https://docs.oracle.com/javase/6/docs/api/java/lang/Enum.html.) Therefore the hashCode for each Enum type is globally unique in a specific contract deployment.
Also I'm not sure if that is the specific reference for Java since than is an API and not the language specification.
How do I update this construction so that a company with $1B of NFT assets at risk will be sufficiently convinced that the statement in bold is true?
The problem is that this isn't true of hashCode()
, in general, just the hashCode()
among AVM Enum
types.
Also, the user is more likely to be looking at the normal JDK documentation than the AVM-specific variant.
These 2 points combined lead me to think that this should be documented elsewhere and more specifically to Enum
s.
We agree that the location the PR puts it is wrong.
Right now I’m trying to develop the statement just relating to Enums. It seems we agree the statement is true. Please confirm explicitly if this is the case or propose an alternative.
Next we can find a good place to put the statement.
The "Consequences" section of this page describes what you are looking for: https://github.com/aionnetwork/AVM/wiki/Hash-Code
Thank you, that resolves the issue.
Used at : https://github.com/fulldecent/aion-aip040/commit/635d84363e9a4ef46bcb1ccfd3ce3bb8505b3d28
This isn't really correct, though. The only reason why these are unique for
Enum
instances is that they are all allocated as constants, which are assigned at deployment time such that a duplication would require an impossibly expensive overflow. Also, thehashCode()
can (and should) be over-ridden by user-defined classes and various other types such that this statement wouldn't hold.This is probably the kind of thing which should be documented elsewhere, as it is more of a consequence of how/when
Enum
constants are initialized, as opposed to anything else.