Why Strings as Classes?

[superdan]

Robert Fraser Wrote:

> superdan wrote:
> > yeppers. amend that to o(log n). in d, that rule is a social contract derived from the built-in vector and hash indexing syntax.
> 
> I see what you did thar -- you made up a rule you like and called it a 
> "social contract". Whether it _should be_ a rule or not is debatable, 
> but it is neither a written nor unwritten rule in use right now, so what 
> you said there is a lie.

well i'm exposed. good goin' johnny drama.

in c++ it's written. in d it's not yet. lookin' at std.algorithm i have no doubt it will. so my lie is really a prophecy :D

> First, a hash access is already time unbounded. hash["hello"] where 
> "hello" is not already in the hash will create a hash entry for hello. 
> This requires heap allocation, which can take arbitrarily long. So 
> having unbounded opIndex is in the language already!

hash was always an oddball. it is acceptable because it offers constant time [] on average.

> Second, opIndex can be used for things other than data structures. For 
> example, if I had a handle to a folder that had a file "foo.txt" in it, 
> folder["foo.txt"] seems a natural syntax to create a handle to that file 
> (which allocates memory = time unbounded).

guess i wouldn't be crazy about it. but yeah it works no problem.

s'pose there's a misunderstanding s'mewhere. i'm not against opIndex usage in various data structs. no problem! i am only against opIndex masquerading as random access in a collection. that would allow algos thinkin' they do some effin' good iteration. when in fact they do linear search each time they make a pass. completely throws the shit towards the fan.

> I can see the opIndex syntax 
> being used for things like properties that may require searching through 
> a parse tree. Maybe this is sort of stretching it, but I wouldn't mind 
> having the opIndex syntax as a shorthand for executing database queries, 
> i.e. `auto result = db["SELECT * FROM posts WHERE from = 'superdan']";`.
> 
> It's a shorthand syntax that makes no guarantees as far as complexity 
> nor should it.

kinda cute, but 100% agree.