Why Strings as Classes?

[superdan]

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.

relax. believe me i'm tryin', maybe you could put it a better way and meet me in the middle.

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

so far so good. 

> Presumably. people will be so into those strings that they'll write a 
> shitload of functionality for them. Parsing, searching, sorting, 
> indexing... the motherload.

cool.

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

i'm in nirvana.

> 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 maestro. the interface call is already what's costing.

> But only if the interface exists.
> 
> And only if library authors write their text-processing code against 
> that interface.
> 
> That's the point.

then there was none. sorry.

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

no. this is just wrong. perfectly backwards in fact. a low-level builtin allows unbounded architectures with control over efficiency.