Why Strings as Classes?

[superdan]

Denis Koroskin Wrote:

> On Wed, 27 Aug 2008 00:30:07 +0400, Steven Schveighoffer  
> <schveiguy at yahoo.com> wrote:
> 
> > "Denis Koroskin" wrote
> >> On Tue, 26 Aug 2008 23:29:33 +0400, superdan <super at dan.org> wrote:
> >> [snip]
> >>>> The D spec certainly doesn't make any guarantees about
> >>>> the time/memory complexity of opIndex; it's up to the implementing  
> >>>> class
> >>>> to do so.
> >>>
> >>> it don't indeed. it should. that's a problem with the spec.
> >>>
> >>
> >> I agree. You can't rely on function invokation, i.e. the following might
> >> be slow as death:
> >>
> >> auto n = collection.at(i);
> >> auto len = collection.length();
> >>
> >> but index operations and properties getters should be real-time and have
> >> O(1) complexity by design.
> >>
> >> auto n = collection[i];
> >> auto len = collection.length;
> >
> > less than O(n) complexity please :)  Think of tree map complexity which  
> > is
> > usually O(lg n) for lookups.  And the opIndex syntax is sooo nice for  
> > maps
> > :)
> >
> > In general, opIndex just shouldn't imply 'linear search', as its roots  
> > come
> > from array lookup, which is always O(1).  The perception is that x[n]  
> > should
> > be fast.  Otherwise you have coders using x[n] all over the place  
> > thinking
> > they are doing quick lookups, and wondering why their code is so damned
> > slow.
> >
> > -Steve
> >
> >
> 
> Yes, that was a rash statement.

i'm kool & the gang with log n too. that's like proportional 2 the count of digits in n.

undecided about sublinear. like o(n^.5). guess that would be pushin' it. but they come by rarely so why bother makin' a decision :)