Why Strings as Classes?

[Robert Fraser]

Benji Smith wrote:
> superdan wrote:
>> Benji Smith Wrote:
>>
>>> BCS wrote:
>>>> Ditto, D is a *systems language* It's *supposed* to have access to 
>>>> the lowest level representation and build stuff on top of that
>>> But in this "systems language", it's a O(n) operation to get the nth 
>>> character from a string, to slice a string based on character 
>>> offsets, or to determine the number of characters in the string.
>>>
>>> I'd gladly pay the price of a single interface vtable lookup to turn 
>>> all of those into O(1) operations.
>>
>> dood. i dunno where to start. allow me to answer from multiple angles.
>>
>> 1. when was the last time looking up one char in a string or computing 
>> length was your bottleneck.
>>
>> 2. you talk as if o(1) happens by magic that d currently disallows.
>>
>> 3. maybe i don't want to blow the size of my string by a factor of 4 
>> if i'm just interested in some occasional character search.
>>
>> 4. implement all that nice stuff you wanna. nobody put a gun to yer 
>> head not to. understand you can't put a gun to my head to pay the price.
> 
> Geez, man, you just keep missing the point, over and over again.
> 
> Let me make one point, blisteringly clear: I don't give a shit about the 
>   data format. You want the fastest strings in the universe, implemented 
> with zero-byte magic beans and burned into the local ROM. Fantastic! I'm 
> completely in favor of it.
> 
> Presumably. people will be so into those strings that they'll write a 
> shitload of functionality for them. Parsing, searching, sorting, 
> indexing... the motherload.
> 
> One day, I come along, and I'd like to perform some text processing. But 
> all of my string data comes from non-magic-beans data sources. I'd like 
> to implement a new kind of string class that supports my data. I'm not 
> going to push my super-slow string class on anybody else, because I know 
> how concerned with performance you are.
> 
> But check this out... you can have your fast class, and I can have my 
> slow class, and they can both implement the same interface. Like this:
> 
> interface CharSequence {
>   int find(CharSequence needle);
>   int rfind(CharSequence needle);
>   // ...
> }
> 
> class ZeroByteFastMagicString : CharSequence {
>   // ...
> }
> 
> class SuperSlowStoneTabletString : CharSequence {
>   // ...
> }
> 
> Now we can both use the same string functions. Just by implementing an 
> interface, I can use the same text-processing as your 
> hyper-compiler-optimized builtin arrays.
> 
> But only if the interface exists.
> 
> And only if library authors write their text-processing code against 
> that interface.
> 
> That's the point.
> 
> A good API allows multiple implementations to make use of the same 
> algorithms. Application authors can choose their own tradeoffs between 
> speed, memory consumption, and functionality.
> 
> A rigid builtin implementation, with no interface definition, locks 
> everybody into the same choices.
> 
> --benji

Superdan is confusing the issues here. The main argument against your 
proposal (besides backwards compatibility, of course) is that every 
access would require a virtual call, which can be fairly slow.