YANAGAWA Kazuhisa wrote:

>In message <3E05E170.30103 / iastate.edu>
>ms / iastate.edu writes:
>
>  
>
>>Has anyone ever proposed making Hash#+ a nondestructive equivalent of 
>>Hash#update ?
>>    
>>
>
>Just my obfuscated memory but....
>
>It was proposed early days and was denied due to a semantic problem,
>and that was the reason Hash#update was introduced.
>
>
>  
>
>>I'm experimenting with keyword arguments and find myself passing things 
>>like h1.dup.update(h2), where h1+h2 would feel more natural.  h1 is 
>>usually some often-used package of default args, and h2 specifies a few 
>>changes and/or additions.
>>    
>>
>
>That's exactly the problem: That causes h1+h2 and h2+h1 yield
>different hashes.  Is this enough reasonable meaning?  OK, String#+
>has also such meaning, however it is concatenation and both operands
>are fully preserved in a result.
>
>
>Who can define good semantics with that "general" people agree under
>the name of `Hash#+'?
>

As you say, non-commutative '+' is common enough in programming. 
 Array#+ is another example.  Consider also that there is an intuitive 
temporal sense to these expressions.  In (hash1 + hash2), we are 
starting with hash1.  After hash2 is brought into the picture, the newer 
bits would be expected to take precedence.  I don't really see a problem 
here.

Regarding both operands being preserved, this is a good point, but in 
none of the other '+' methods (numbers, strings, arrays) can the 
operands quite be recovered from the result.  You get a new object that 
is different from the first two; the operands were brought together in a 
way that makes sense for the type.

>
># While Hash#update is an enough reasonable name, isn't it?
>

True, but Hash#update lives over in Destructive Methods Land. :-)

>
>On the other hand large number of people won't be confused,
>`h1.dup.update(h2)' is good candidate of meaning of Hash#+.
>

That really sums it up. I don't think Hash#+ can reasonably have a 
different meaning.

>
># To vote?
>
>  
>