| Summary: | Introduce UniquePropertyID class instead of using StringImpl* as uid | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Yusuke Suzuki <ysuzuki> |
| Component: | JavaScriptCore | Assignee: | Yusuke Suzuki <ysuzuki> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | darin, fpizlo, ggaren |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 144438 | ||
| Bug Blocks: | |||
Hm, but, if these use cases are rare enough, we can go without this fix. 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 . *** This bug has been marked as a duplicate of bug 144848 *** |
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*. // ... };