[webkit-dev] some WebCore::String plans

[Darin Adler]

On Dec 18, 2007, at 6:19 PM, Maciej Stachowiak wrote:

>> 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.

I was thinking they could be free functions that return a  
PassRefPtr<StringImpl>. That seems like a wart -- not sure where these  
should go.

>> 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+.

I like += better too. We don't necessarily need to keep the << syntax.  
Or we could have both.

> 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().

I was thinking of Vector<UChar>. The release() function would use the  
adopt function that takes a Vector<UChar>.

The get() is less important. It should probably be named copy() instead.

>> - 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.

I think you are right.

     -- Darin

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