[concurrency-interest] Concurrency-interest Digest, Vol 37, Issue 7

Mark Mahieu mark at twistedbanana.demon.co.uk
Sun Feb 10 12:10:48 EST 2008


> You're right about "ouch" - 1828 interfaces!
>
> Seems you can reduce the footprint some; all the *ToBoolean and  
> *Predicate interfaces are duplicates

Yes, but which to remove?  The *Predicates are distinguished by  
having a meaningful name and associated javadoc, so they strike me as  
the more 'deserving' of their place.   Yet the *ToBoolean interfaces  
provide a degree of consistency with the remainder of the general Op  
interfaces.

> However, you do not define any *WithException procedures or  
> generators. What is the rationale for that?
> I.e. why does the necessity for *WithException ops elsewhere not  
> apply to procedures and generators?

Good spot - that's an oversight on my part.  Thanks!

> But is seems removing the *WithException ops would be a good option  
> to simplify things and instead push
> RuntimeException handing into the frameworks.

Depends on the framework, and as Josh says, what improvements we get  
at the language level.  Since I'm looking at all this from the  
perspective of possible language changes, I'd rather not push them  
under the carpet just yet.  But they are nasty.

>
> Is it necessary to specialize on byte vs short vs int vs long  
> parameters; seems like
> implicit widening to int or long should suffice and you can  
> eliminate a lot of combinations.
> It seems sufficient for jsr166y.forkjoin.

Personally, I'd prefer it if there were no need to define any of the  
specializations, with only about half a dozen new interfaces provided  
in total - Generator, Predicate/BinaryPredicate, Procedure, Reducer  
and maybe Op/BinaryOp.

Yet to me approaches such as this all imply that we either accept  
that other frameworks which need specializations will each have to  
define their own versions of those interfaces (probably with their  
own naming conventions and other idiosyncrasies), or we improve the  
language somehow so that it becomes unnecessary for them to do so.

It could be argued that this won't be a problem in practice - that  
these operation/function types employed by jsr166y.forkjoin are  
rarely required, and will remain so.  The evidence I'm seeing  
suggests quite strongly otherwise, but we shall see.

Thanks for your comments :)

> -- 
> David J. Biesack     SAS Institute Inc.
> (919) 531-7771       SAS Campus Drive
> http://www.sas.com   Cary, NC 27513


Mark




More information about the Concurrency-interest mailing list