On 22/02/2013 06:38, Marvin Humphrey wrote:
On Thu, Feb 21, 2013 at 4:43 AM, Nick Wellnhofer <[email protected]> wrote: How about a three-prong strategy which uses both of those approaches and adds one more?* Externally, expose iterators as full-blown, opaque objects. * Internally, allocate iterators on the stack using alloca() and access the struct members directly. * To accommodate highly performance-sensitive client code, provide access to raw string data, so that the client can operate on it using its own highly optimized and customized routines.
+1
This remains a problem if we make CharBuf a subclass of String. If safe iteration is part of String's interface, then a mutable subclass which cannot support safe iteration violates the Liskov Substitution Principle[1].
Doesn't a mutable subclass of an immutable class already violate the Liskov Substitution Principle? See "history constraint" on the Wikipedia page.
Nick
