[webkit-dev] some WebCore::String plans

[Maciej Stachowiak]

Mostly sounds good.

On Dec 18, 2007, at 10:51 AM, Darin Adler wrote:

> The WebCore::String class needs some work. I have some plans to  
> improve it. Here's an outline of what I have in mind.
>
> immutability
> - eliminate all non-const functions from StringImpl; fixes tricky  
> sharing semantics
> - change all uses of const StringImpl* to just plain StringImpl*  
> because there will no longer be any real difference between these  
> types
> - then, once RefCounted is made thread-safe, then we could remove  
> the copy() function altogether, since the only reason to use it  
> would be thread safety
>
> ownership
> - change functions that return StringImpl* to return  
> PassRefPtr<StringImpl> instead, if they sometimes make a new object;  
> makes it harder to accidentally leak
> - change functions that take StringImpl* to take  
> PassRefPtr<StringImpl> instead if they take ownership; can reduce  
> reference count churn
> - make a release() function on String that returns a  
> PassRefPtr<StringImpl>; can reduce reference count churn
>
> clarity
> - eliminate functions that return a StringImpl* from StringImpl,  
> because it's to easy to misunderstand and think these modify the  
> string in place
> - eliminate functions that return a String from String -- also easy  
> to use wrong for the same reasons

Where would we put functions that take a string and return a modified  
one? Seems like we'll still want those, if our string type becomes  
truly immutable.

>
> performance
> - change TextStream into a class named StringBuilder for clients  
> that are building up strings (name inspired by Java); it will have  
> get() and release() functions that will return PassRefPtr<StringImpl>

I kind of like the += syntax for a StringBuilder better than the <<  
syntax, but I guess that's harder to use if there's no operator+. It  
seems like the obvious implementation techniques are making a  
Vector<UChar> and appending to it, or keeping a Vector<StringImpl>,  
neither of those would play well with a non-releasing get().

> - add functions that take a PassRefPtr<StringImpl> and return a  
> PassRefPtr<StringImpl> for many string operations, since those can  
> optimize the "only one reference" case and re-use the same character  
> buffer; change the String class to use those as appropriate
> - rename the String::impl() function to String::get() to match other  
> RefPtr classes
> - consider eliminating String and using RefPtr<StringImpl> at most  
> or all call sites
> - consider changing call sites that take a const String& to instead  
> take StringImpl* or PassRefPtr<StringImpl>
>
> names
> - rename StringImpl to SharedString
> - consider renaming WebCore::String to StringRefPtr since it's a  
> lightweight wrapper around a RefPtr; one benefit is that it would  
> allow us to eliminate the header name PlatformString.h

If you did both of those things, a better name for SharedString might  
be String.

>
> These plans are still a bit rough. Please let me know what you  
> think. Depending on what feedback I get, I might make a Wiki page  
> about this.
>
> Some of this I will do soon. Some of it is longer-term.
>
>     -- Darin
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20071218/a8ec8ae9/attachment-0001.html