> 
> No.  Arguments are:
> 
> "+" is inefficient. (same for "-")

dito with 
"string" += "other_string"
but ok, we can skip this

> 
> "<<" has usually the semantics that the left side is a collection while
> the right side is an element.  And since each entry in a Hash needs a key
> value pair this could not be done with <<, because "<<" can only have a
> single argument.


what about 

	"a" << "bcd"

or

	["a"] << ["b", ["c", "d"], "e"]
?


>  You could only implement << in a way that "h << [key,
> value]" would add the pair (key, value), but this is by no means clearer
> than "h[key] = value" IMHO.

- you can iterate above hashs and arrays without taking care if they are hashs or arrays.
- you only have to learn one syntax
- ....


 
> see Array: [1]<<[2] yields [1,[2]] and not [1,2]
> 
but 'a'  << "bcd" yields 'abcd' and not 'a"bcd"' 

so thats special to the array-class. but it should neccessarily affect hashes.

1 << 3 #-> 8 
thats special to the Fixnum class so you have to learn that behaviour anyway


> Again, this is not symmetric with other occurences of "-": left and right
> side should be of the same type, at least both should be containers, i.e.
> hashes in this case.

I could agree with that. just thought that the second way would be useful (-> delete)

> What should it do if the Hash contains Hashes as keys?  This is highly
> ambiguous and not intuitive.

no, its quite clear: it happens the same thing like

myhash[{"key" => "val"}] = "other_val"

benny