[concurrency-interest] jsr166y.forkjoin.Ops vs the world outside

David J. Biesack David.Biesack at sas.com
Mon Feb 11 14:26:31 EST 2008


> Date: Sun, 10 Feb 2008 17:10:48 +0000
> From: Mark Mahieu <mark at twistedbanana.demon.co.uk>
> > I <David.Biesack at sas.com> wrote
> > 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.

Have you thought about inverting the names, i.e.

public class ToBoolean {

    public interface OfBoolean {
        boolean of(boolean arg0);
    }

    public interface OfInt {
        boolean of(int arg0);
    }
    // ...
    public interface OfIntAndDouble {
        boolean of(int arg0, double arg1);
    }
    // and so on for all the other argument combinations

    ToBoolean() { // no sublcasses in other packages
        throw new AssertionError("no instantiation allowed");
    }
}

public class Predicate extends ToBoolean { 
  Predicate() {
     throw new AssertionError("no instantiation allowed");
  }
}

public class ToInt {

    public interface OfBoolean {
        int of(boolean arg0);
    }

    public interface OfInt {
        int of(int arg0);
    }
    // ...
    public interface OfIntAndDouble {
        int of(int arg0, double arg1);
    }
    // and so on for all the other argument combinations


    ToInt() { // no sublcasses in other packages 
        throw new AssertionError("no instantiation allowed");
    }

}

  // and so on:
  // java.util.ToBoolean
  // java.util.Predicate
  // java.util.ToByte
  // java.util.ToShort
  // java.util.ToChar
  // java.util.ToInt
  // java.util.ToLong
  // java.util.ToFloat
  // java.util.ToDouble
  // concluding with:

public class Procedure {

    public interface OfBoolean {
        void of(boolean arg0);
    }

    public interface OfInt {
        void of(int arg0);
    }
    // ...
    public interface OfIntAndDouble {
        int of(int arg0, double arg1);
    }
    // and so on for all the other argument combinations

    private Procedure() {
        throw new AssertionError("no instantiation allowed");
    }
}


The frameworks would use ToBoolean, but people could use Predicate,
and the API (and jar size and classloader memory) footprint 
is not greatly impacted.

I concede that this sort of use of classes for namespace management
may be ugly to some (many?), but this is not much worse that jsr166y.forkjoin.Ops.

Of note: Eclipse (3.3) cannot do code completion on Predicate.To{...} but NetBeans can.

client use:

    final Predicate.OfInt predicate = new Predicate.OfInt() {

            public boolean of(int arg0) {
                ...
            }
        };

    final ToInt.OfIntAndDouble intFunction = new ToInt.OfIntAndDouble() {

            public int of(int arg0, double arg1) {
                ...
            }
        };

    final Procudure.OfDouble proc = new Procedure.OfDouble() {

            public void of(double arg0) {
                ...
            }
        };

    boolean a = predicate.of(true)
    int b = intFunction.of(0, 1.0)
    proc.of(1.0)

Note also that rather than naming the method "op", I named them
"of" which seems to read better; "on" is also an option:

    boolean a = predicate.on(true)
    int b = intFunction.on(0, 1.0)
    proc.on(1.0)

Another nice side effect is that the package level javadoc does not look too awful.

> 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), 

I doubt any of us want that...

> or we improve the  
> language somehow so that it becomes unnecessary for them to do so.

where are these language extensions being proposed?
 
> 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.

I agree that it won't go away if we ignore it.

> Thanks for your comments :)
>
> Mark

-- 
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 mailing list