Bug 144440 – Introduce UniquePropertyID class instead of using StringImpl* as uid

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: JavaScriptCore

[Yusuke Suzuki]

To prevent the symbolized StringImpl* with the other string in their contents accidentally, I'm now planning to introduce a new class such as UniquePropertyID.

In UniquePropertyID, we prohibit comparison in their contents. Pointer comparison is only allowed. This is the replacement to StringImpl* uid usage.

The typical implementaion is the following...

class UniquePropertyID : private StringImpl {
    using existingSymbolAwareHash;
    using symbolAwareHash;
    using isSymbol;

    StringImpl* publicName()
    {
       return isSymbol() ? nullptr : this;
    }

    // Factory functions from StringImpl*.
    // ...
};

[Yusuke Suzuki]

Hm, but, if these use cases are rare enough, we can go without this fix.

[Yusuke Suzuki]

After considering about it, I think this case is a little bit rare. Because when using StringImpl* would be used for Identifier, it is already atomized / symbolized by Identifier class. So places we need to take care is when comparing StringImpl* (which is used as uid) and the other strings .

[Yusuke Suzuki]

*** This bug has been marked as a duplicate of bug 144848 ***