[concurrency-interest] Ops type names

Joshua Bloch josh at bloch.us
Mon Jan 14 19:53:07 EST 2008


David,

Hi.  I understand your desire consistency.  That said, I was inconsistent
"with my eyes open."  Worse, I violated the norms in mathematics.  When a
mathematician speaks of a real-function, he speaks of the range (result
type), irrespective of the domain.  That said, when it comes to designing
APIs, I like to take the nice, short names for the common cases, and I
believe that the case of functions whose range and domain types are the same
will predominate (whether it's int-to-int, long-to-long, or
double-to-double).  So, I stole the nice names for the common homogeneous
function types.

         Josh

On Jan 14, 2008 2:15 PM, David J. Biesack <David.Biesack at sas.com> wrote:

>
> > Date: Fri, 11 Jan 2008 10:37:56 -0500
> > From: Doug Lea < dl at cs.oswego.edu>
> > Subject: Re: [concurrency-interest] Ops type names
> > To: concurrency-interest at cs.oswego.edu
> >
> > Courtesy of some suggestions by Josh Bloch, I'll be revamping
> > Ops type names in the near future. Plus incorporate new methods such as:
> >    WithMapping<V> withMapping(BinaryOp<T, U, V>, ParallelArray<U> other)
>
> >      (BinaryOp was "Combiner"; wildcards omitted here for clarity.)
> > which replaces the "combine" methods with more flexible operation
> > prefix support.
> >
> > Sorry as always for the disruption to those of you using
> > this framework. Hopefully we are getting near the end of
> > these kinds of incompatible changes.
> >
> > -Doug
>
> While in general I find the new naming scheme to be a big improvement,
> and I like the generic types names A (argument) and R (result)
> over the previous non-mnemonic names or the F/T (from/to) names I
> posted earlier, 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!]
>
> Humbly,
>  djb
>
> --
> David J. Biesack     SAS Institute Inc.
> (919) 531-7771       SAS Campus Drive
> http://www.sas.com   Cary, NC 27513
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080114/303649bc/attachment.html 


More information about the Concurrency-interest mailing list