support for operators

[kbwelker]

I am considering indirect support for numeric operators. No time to
detail it right now, but it occurred to me that one of the weaknesses
of Funcito is its inability to do anything other than wrap existing
methods. If we could get simple transformations added for numeric
types (plus(? extends Number), minus(...), times(), divide() ), and
comparison operators that convert non-boolean method to Predicate
(lt(), gt(), eq(), le(), ge()), it might significantly improve
flexibility without sacrificing brevity.

I am thinking of syntax that might look like:

Function<X,Integer> f =
functionFor( callsTo(X.class).someIntMethod() ).plus(3);

and below (notice slightly different syntax from above, i.e. extra
arg)

Predicate<X> p = predicateFor( callsTo(X.class).someIntMethod(),
lt(10));

We could also throw in other operators possibly, possibly "not()" to
invert a boolean method value

[kbwelker]

Pondering my own proposal above for operators, I originally had the
function transformationByOperators append to the functionFor()
result. But that would require that the return type from
functionFor() be some Funcito type that extends Guava Function.
Seemingly not a big deal -- except that we support multiple libraries,
so we would need to extend *each* of the Function-like types supported
in each of the libraries. Again, not a big deal, except that I don't
think we could reuse any base implementation because of lack of
multiple inheritance in Java. So we would have to reimplement each
operator for each library.

If instead, we pass the "op"-method-call as an arg to the
functionFor() (like I did in the predicate transformation example), I
think we would find that we could obtain reuse across libraries. I'd
have to try it out to be sure.

But if our supported base of libraries remains small, simplicity/
efficiency may just suggest avoiding the reuse rabbit hole and
manually implementing the ops independently for each supported library.

[kbwelker]

Also to note, some libraries already have some operators like OR, AND,
NOT defined -- actually most of the libraries define those logical
operators (even XOR sometimes). See jedi FirstOrderLogic, Guava
Predicates.

[kbwelker]

Thinking about operators for functions that require particular types
(like numeric types for numeric ops), I am thinking there is no way to
get compile time checking of types. In other words, if you can do
something like:

Function<X,Integer> f =
functionFor( callsTo(X.class).someIntMethod() ).plus(3);

then what would prevent something like the following from also
compiling:

Function<X,Integer> f =
functionFor( callsTo(X.class).someNonNumericMethod() ).plus(3);

Yes, we could have runtime checking, but that would be less pleasant.
I think the same goes for the alternate parameterized form, but I will
have to ponder that further.