[functor] Suggested functor changes

[Brian Eubanks <jo...@eubot.com>]

Here are some things I'd like to see in commons-functor:

1. The functors need a common superinterface, even if it's empty. I've 
added this as a suggested enhancement in the bug tracker. I'd also like 
to add empty marker interfaces for each general category. This will make 
writing metadata and meta-functors much easier.
Here is my proposed hierarchy (slightly different from the bug entry). 
This does not affect the names of any existing interfaces.

// grandmother of all functors
public interface Functor {}

// marker interfaces
public interface Nullary {}  // nullary means 0 parms
public interface Unary {}  // 1
public interface Binary {}  // 2
public interface Trinary {}  // 3
public interface Quaternary {}  // 4
public interface Quintary {} // 5
public interface AnyArity {}  // any

// anything of any arity, that returns an Object
public interface AbstractFunction extends Functor {}
// anything of any arity, that returns a boolean
public interface AbstractPredicate extends Functor {}
// anything of any arity, that returns void
public interface AbstractProcedure extends Functor {}

// I'd like to rename this one to NullaryFunction :-)
// but it would affect existing code
public interface Function extends AbstractFunction, Nullary { ... }
public interface UnaryFunction extends AbstractFunction, Unary { ... }
public interface BinaryFunction extends AbstractFunction, Binary { ... }
// ... also add trinary, quaternary, and quintary functions
// this should have been NullaryPredicate
public interface Predicate extends AbstractPredicate, Nullary { ... }
// and unary through quintary predicates
// this should have been NullaryProcedure
public interface Procedure extends AbstractProcedure, Nullary { ... }
// and unary through quintary procedures

2. Add a universal-arity function, predicate and procedure.
Although this is like a unary process, desired behavior could be 
different for arrays than for other objects. I can imagine functions 
that are both an AnyArityFunction and a UnaryFunction, yet return 
different results for the different parameters.
The expected contract is that a null parameter is treated as a 
zero-length array.
public interface AnyArityFunction extends AbstractFunction, AnyArity {
  public Object[] evaluate(Object[] x);
}
public interface AnyArityPredicate extends AbstractPredicate, AnyArity {
  public boolean test(Object[] x);
}
public interface AnyArityProcedure extends AbstractProcedure, AnyArity {
  public void run(Object[] x);
}

3. Add adapters to automatically convert between the AnyArity types and 
unary, binary, trinary, etc.

4. Add a FunctorMetadata class, so that programs using functors can use 
higher-order logic in a consistent way (meta-functors). This is made 
easier by the new superinterfaces.
public class FunctorMetadata {
   public int getArity();    // (for AnyArity types, returns max int value)
   public Class getReturnType();
}

5. Add MetaFunctor interfaces. Although this is really a unary function, 
sometimes you'll want to force the parameter to be a functor, for 
writing function transformers.
public interface UnaryMetaFunctorFunction extends AbstractFunction, Unary {
    public Functor evaluate(Functor x);
}

6. Add reflection adapters for calling methods and bean properties 
(using Commons-BeanUtils). This allows real methods to easily become 
functors.

7. Add Java 5 generics support. (This should wait, because we probably 
don't want to require Java 5 yet.)

Comments, anyone?

Regards,
Brian



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org