[concurrency-interest] Ops type names

[Doug Lea]

David J. Biesack wrote:
> it pains me to say I have a small disagreement with one 
> part of the new names. I think there is still inconsistency that can 
> be removed.
> 
> While we have
> 
>   Ops.IntToDouble :: double op(int a) 
>   Ops.IntToLong   :: long op(int a) 
>   Ops.IntToObject :: R op(int a) 
> and
>   Ops.ObjectToInt :: int op(A a) 
> 
> there is
> 
>   Ops.IntOp ::  int op(int a) 
>  
> which, to me, sticks out like a sore thumb. I contend that 
> 
>   Ops.IntToInt ::  int op(int a) 
> 
> would be more consistent in the long run.
> (Similarly for DoubleOp => DoubleToDouble, LongOp => LongToLong.)
> 
> I think diverging from the {arg-types}To{result-type} pattern will
> cause a lot of confusion down the road. The name IntOp just does
> not indicate whether the argument or the result type is int,
> and the fact that its both does not really help.
> 
> [Side note: At first, I thought
> 
>   Ops.Op :: R op(A a) 
>   Ops.BinaryOp :: R op(A a, B b) 
> 
> should become
> 
>   Ops.ObjectToObject :: R op(A a) 
>   Ops.ObjectAndObjectToObject :: R op(A a)
> 
> to further enforce consisteny, but after thinking more, 
> I agree with the names Ops.Op/Ops.BinaryOp Yes, I realize
> that I'm being inconsistent!]
> 

Yes, and this is exactly the line of thought that led to IntOp
and BinaryIntOp -- that is, which of these patterns should the
simplest and by far most common scalar cases conform to?
It could go either way, but for these common ones,
better-sounding-ness seems to win out.

Since it could go either way though, if enough others agree
with you, I'd be happy to change them.

-Doug