[concurrency-interest] Concurrency-interest Digest, Vol 37, Issue 7
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
> 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
More information about the Concurrency-interest