[concurrency-interest] Ops type names

Neal Gafter neal at gafter.com
Mon Jan 14 18:59:07 EST 2008


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!]


I wonder if we could provide some sort of small language extension to make
these names easier to remember, write, and read. So, for example, instead of
making people write

Ops.ObjectAndIntToObject<? Super String, ? extends Student>

we could allow them to alternatively indicate the type by writing some
syntax like

{ String, int => Student }
 or
( String, int ) => Student

-Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080114/bff777b0/attachment.html 


More information about the Concurrency-interest mailing list