| Summary: | Fix the incorrectness that AtomicString could have symbolic StringImpl | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Yusuke Suzuki <ysuzuki> |
| Component: | Web Template Framework | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | darin, kling |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 144848 | ||
| Bug Blocks: | |||
|
Description
Yusuke Suzuki
2015-05-14 08:44:07 PDT
(In reply to comment #0) > + Since there's code using `operator==` for AtomicString, rewriting is not > mechanical. I don’t understand the problem here. One of the properties of AtomicString is that == is the same operation for AtomicString, for AtomicStringImpl*, and for RefPtr<AtomicStringImpl>. Unlike String, where String's == compares the characters, but StringImpl* and RefPtr<StringImpl> are not the same. Another plus of using RefPtr directly is that it will be more natural to pass types like UniquedStringImpl& and UniquedStringImpl*, rather than const RefPtr<UniquedStringImpl>&, and the former is more efficient. In fact, we would eventually rename UniquedStringImpl to UniquedString, once we figure out what to do about the names of WTF::String and WTF::StringImpl. I think we might at some point name WTF::String something crazy like RefPtrString and give StringImpl the simpler name String. |