Why Strings as Classes?

[Dee Girl]

Nick Sabalausky Wrote:

> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message 
> news:g95b89$1jii$1 at digitalmars.com...
> >
> > When someone sees an index operator the first thought is that it is a 
> > quick lookup.
> 
> This seems to be a big part of the disagreement. Personally, I think it's 
> insane to look at [] and just assume it's a cheap lookup. That's was true in 
> pure C where, as someone else said, it was nothing more than a shorthand for 
> a specific pointer arithmentic operation, but carrying that idea over to 
> more modern languages (especially one that also uses [] for associative 
> arrays) is a big mistake.
> 
> The '+' operator means "add". Addition is typically O(1). But vectors can be 
> added, and that's an O(n) operation. Should opAdd never be used for vectors?

This is big, big mistake! I think I do not know how to explain it. I could not so far because we talk from one mistake to other.

If you add vector a[] = b[] + c[] then that is one operation that is repeat for each element of vector. Complexity is linear in cost of one operation. It would be mistake if each + take O(a.length). In other case it is simply as expected proportional to length of input.

> > You can force yourself to think differently, but the reality is that most 
> > people think that because of the universal usage of square brackets 
> > (except for VB, and I feel pity for anyone who needs to use VB) to mean 
> > 'lookup by key', and usually this is only useful on objects where the 
> > lookup is quick ( < O(n) ).  Although there is no requirement, nor 
> > enforcement, the 'quick' contract is expected by the user, no matter how 
> > much docs you throw at them.
> >
> > Look, for instance, at Tango's now-deprecated LinkMap, which uses a 
> > linked-list of key/value pairs (copied from Doug Lea's implementation). 
> > Nobody in their right mind would use link map because lookups are O(n), 
> > and it's just as easy to use a TreeMap or HashMap.  Would you ever use it?
> >
> >> If you *really* need that sort of guarantee (and I can imagine it may be 
> >> useful in some cases), then the implementation of the guarantee does 
> >> *not* belong in the realm of "implements vs doesn't-implement a 
> >> particular operator overload". Doing so is an abuse of operator 
> >> overloading, since operator overloading is there for defining syntactic 
> >> sugar, not for acting as a makeshift contract.
> >
> > I don't think anybody is asking for a guarantee from the compiler or any 
> > specific tool.  I think what we are saying is that violating the 'opIndex 
> > is fast' notion is bad design because you end up with users thinking they 
> > are doing something that's quick.  You end up with people posting 
> > benchmarks on your containers saying 'why does python beat the pants off 
> > your list implementation?'.  You can say 'hey, it's not meant to be used 
> > that way', but then why can the user use it that way?  A better design is 
> > to nudge the user into using a correct container for the job by only 
> > supporting operations that make sense on the collections.
> >
> > And as far as operator semantic meaning, D's operators are purposely named 
> > after what they are supposed to do.  Notice that the operator for + is 
> > opAdd, not opPlus.  This is because opAdd is supposed to mean you are 
> > performing an addition operation.  Assigning a different semantic meaning 
> > is not disallowed by the compiler, but is considered bad design.  opIndex 
> > is supposed to be an index function, not a linear search.  It's not called 
> > opSearch for a reason.  Sure you can redefine it however you want 
> > semantically, but it's considered bad design.  That's all we're saying.
> >
> 
> Nobody is suggesting using [] to invoke a search (Although we have talked 
> about using [] *in the search function's implementation*). Search means you 
> want to get the position of a given element, or in other words, "element" -> 
> search -> "key/index". What we're talking about is the reverse: getting the 
> element at a given position, ie, "key/index" -> [] -> "element". It doesn't 
> matter if it's an array, a linked list, or a 
> super-duper-collection-from-2092: that's still indexing, not searching.

I think this is also big mistake. I am so sorry! I can not explain it. But it looks you think if you call it different it behaves different. Sorry, Dee Girl