Why Strings as Classes?

[Dee Girl]

Michiel Helvensteijn Wrote:

> Dee Girl wrote:
> 
> >> >> But putting that aside for the moment, are you saying you would allow
> >> >> yourself to be deceived by a syntax detail? No, mentally attaching
> >> >> O(1) to the *subscripting operator* is simply a legacy from C, where
> >> >> it is syntactic sugar for pointer arithmetic.
> >> > 
> >> > I do not think so. I am sorry. If a[n] is not allowed then other array
> >> > access primitive is allowed. Give index(a, n) as example. If language
> >> > say index(a, n) is array access then it is big mistake for list to also
> >> > define index(a, n). List maybe should define findAt(a, n). Then array
> >> > also can define findAt(a, n). It is not mistake.
> >> 
> >> Yes, I agree for "array access". That term implies O(1), since it uses
> >> the word "array". But I was argueing against the subscripting operator to
> >> be forced into O(1).
> > 
> > I am sorry. I do not understand your logic. My logic was this. Language
> > has a[n] for array index. My opinion was then a[n] should not be linear
> > search. I said also you can replace a[n] with index(a, n) and my same
> > reason is the same. How are you argueing?
> 
> Let me try again. I agree that you may impose complexity-restrictions in
> function contracts. If you write a function called index(a, n), you may
> impose the O(log n) syntax, for all I care. But the a[n] syntax is so
> convenient that I would hate for it to be likewise restricted. I would like
> to use it for lists and associative containers and the complexity may be
> O(n). The programmer should just be careful.

Thank you for trying again. Thank you! I understand. Yes, a[n] is very convenient! And I would have agree 100% with you if a[n] was not build in language for array access. But because of that I 100% disagree ^_^.

I also think there is objective mistake. In concrete code programmer can be careful. But in generic code programmer can not be careful. I think this must to be explained better. But I am not sure I can.

> > I did not want to get in this discussion. I see how it is confusing fast
> > ^_^.
> 
> I find much of this subthread confusing. (Starting with the discussion of
> Benji and superdan). It looks to me like 80% of the discussion is based on
> misunderstandings.
> 
> >> Amortized complexity has nothing to do with it. Dynamic arrays have to
> >> copy their elements and lists do not. It's as simple as that.
> > 
> > No, it is not. I am sorry! In STL there is copy. In D there is std.move. I
> > think it only copies data by bits and clears source. And amortized
> > complexity shows that there is o(1) bit copy on many append.
> 
> Yes, a bit-copy would be ok. I was thinking of executing the potentially
> more expensive copy constructor. It's nice that D doesn't have to do this.
> 
> >> STL will choose the right sorting algorithm, given a specific
> >> data-structure. But I am saying it may be possible also for the
> >> data-structure to be automatically chosen, based on what the programmer
> >> does with it.
> > 
> > I think this is interesting. Then why argueing for bad container design? I
> > do not understand. Thank you, Dee Girl.
> 
> Where am I argueing for bad design? All I've been arguing for is looser
> restrictions for the subscripting operator. You should be able to use it on
> a list, even though the complexity is O(n). But if it is used often enough
> (in a deeply nested loop), the compiler will probably automatically use an
> array instead.

The idea is nice. But I think it can not be done. Tool is not mind reader. If I make some insert and some index. They want different structure. How does the tool know what I want fast?

I say you want bad design because tool does not exist. So we do not have the tool. But we can make good library with what we have. I am sure you can write library with a[n] in O(n). And it works. But I say is more inferior design than STL. Because your library allows things that should not work and does not warn programmer.