Add StringView::toExistingAtomicString()

• Component: Web Template Framework
• Status: RESOLVED FIXED

[Daniel Bates]

As suggested by Darin Adler in bug #170925, comment 7 and echoed by Sam Weinig in bug #170925, comment 14, we should add the convenience function StringView::toExistingAtomicString() to return an existing AtomicStringImpl for the string represented by the StringView if one exists. Returning an existing atomic string is more efficient than creating a new one using StringView::toAtomicString().

[Daniel Bates]

Created attachment 308479 [details]
Patch

Is there a reason for the AtomicStringImpl::lookUp() functions taking a non-const pointer to a LChar/UChar? I mean, AtomicStringImpl does not mutate the LChar/UChar* buffer passed when performing a lookup. I am unclear how we came to the decision to have these functions (formerley named AtomicString::find()) take non-const pointers to buffers other than to match the non-constness of the buffer passed by the callers that motiviated the addition of these lookup functions in <http://trac.webkit.org/changeset/168256> (bug #132548). We seemed to explicitly avoid making these lookup functions take a const pointer to a buffer and added AtomicString::findInternal() when we later moved and renamed AtomicString::find() to AtomicStringImpl::lookUp() in <https://trac.webkit.org/changeset/182915> (bug #43404). Why?

[Daniel Bates]

Created attachment 308480 [details]
Patch

[Andreas Kling]

Comment on attachment 308480 [details]
Patch

r=me :)

[Daniel Bates]

Comment on attachment 308480 [details]
Patch

Clearing flags on attachment: 308480

Committed r215947: <http://trac.webkit.org/changeset/215947>

[Daniel Bates]

All reviewed patches have been landed.  Closing bug.