[concurrency-interest] forkjoin.ParallelArray and friends

Larry Riedel larryr at saturn.sdsu.edu
Mon Aug 27 20:25:14 EDT 2007

> > I think the whole API should be interface-based. [...]
> We debated this. I think the current form is an OK compromise
> between too little and too much abstraction. For example, to
> properly generalize ParallelArray as an interface, you'd also
> need to somehow generalize ForkJoinExecutor into something that
> would allow say alternate ParallelArray implementations via say
> GPU parallelism.  Which then gets you into lots of bulky layers
> of interfaces and factories before you can get anything done.

To me the latter approach below is negligibly more burdensome
for the provider of the default implementation, negligibly
more burdensome for the consumer, and negligibly increases
the complexity of the API.  I think there are benefits to
providing an API as interfaces rather than classes which are
orthogonal to whether the API has been "properly generalized".
I, as a default provider, would like to invite people to find
alternative ways to implement the API without lots of bulky
layers of interfaces and factories... or with them if it makes
their overall system implementation simpler.  But I do not mean
to suggest /every/ API should be all interfaces; I do think
maybe a good default choice for a relatively complex general
purpose API is to be interfaces.

    package abc.def;
    public class Ghi { ... }
    public class Jkl { ... }
    import abc.def.Ghi;
    import abc.def.Jkl;
    someGhi = new Ghi();
    someJkl = new Jkl();


    package abc.def;
    public interface Ghi { ... }
    public interface Jkl { ... }
    public static class Def {
        public static Ghi newGhi() { return new DefaultGhi... }
        public static Jkl newJkl() { return new DefaultJkl... }
    import abc.def.Def;
    import abc.def.Ghi;
    import abc.def.Jkl;
    someGhi = Def.newGhi();
    someJkl = Def.newJkl();


More information about the Concurrency-interest mailing list