The Name enum represents both interned strings and indexes. The reason for this is that this simplifies the implementation (we don't need separate methods for indexed access and checks on keys being an index if it's not necessary, e.g. for JsObject). However, a result of this is that index keys (positive numeric keys that are less or equal to i32::MAX) are not interned anymore. Instead we create a new String when the string for such a Name is asked from the interner. This should not be that much of a problem because it is expected that there will be very few such keys in normal usage. However, this must be validated. When doing performance tests, a metric should be made available how many times such a string was created. If it turns out that this assumption does not hold, we may need to revisit this design decision.
The
Nameenum represents both interned strings and indexes. The reason for this is that this simplifies the implementation (we don't need separate methods for indexed access and checks on keys being an index if it's not necessary, e.g. forJsObject). However, a result of this is that index keys (positive numeric keys that are less or equal toi32::MAX) are not interned anymore. Instead we create a newStringwhen the string for such aNameis asked from the interner. This should not be that much of a problem because it is expected that there will be very few such keys in normal usage. However, this must be validated. When doing performance tests, a metric should be made available how many times such a string was created. If it turns out that this assumption does not hold, we may need to revisit this design decision.