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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
