Bug 144440 - Introduce UniquePropertyID class instead of using StringImpl* as uid
Summary: Introduce UniquePropertyID class instead of using StringImpl* as uid
Status: RESOLVED DUPLICATE of bug 144848
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Yusuke Suzuki
URL:
Keywords:
Depends on: 144438
Blocks:
  Show dependency treegraph
 
Reported: 2015-04-30 02:23 PDT by Yusuke Suzuki
Modified: 2015-05-20 10:22 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yusuke Suzuki 2015-04-30 02:23:40 PDT
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*.
    // ...
};
Comment 1 Yusuke Suzuki 2015-04-30 03:01:14 PDT
Hm, but, if these use cases are rare enough, we can go without this fix.
Comment 2 Yusuke Suzuki 2015-05-01 01:43:31 PDT
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 .
Comment 3 Yusuke Suzuki 2015-05-20 10:22:20 PDT

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