Support wrapping multi-parameter methods to functionaljava FN functions.

[GoogleCodeExporter]

1. Static methods
-----------------

A static method

  public static B f(A1 a1, A2 a2) { .. }

could be wrapped into

  F2<A1, A2, B> f .

2. Class methods
----------------

A class method

  class A1 {
      public B f(A2 a2)
  }

could also be wrapped into

  F2<A1, A2, B>

Original issue reported on code.google.com by palotai....@gmail.com on 6 Jun 2012 at 8:25

[GoogleCodeExporter]

changing from defect to enhancement request

Original comment by kandpwel...@gmail.com on 6 Jun 2012 at 2:22

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Related to this proposal is Issue 31.  A question I asked over there 
(http://code.google.com/p/funcito/issues/detail?id=31#c3), regards how to treat 
the static state of the class to which the static function belongs.  In your 
example above, the result of the static method call may not just depend on the 
parameters a1 and a2, but possibly also on static variables of the class.  I 
guess results of *ANY* method call could vary based on static state of the host 
class, or even on public static state or static method calls on other classes, 
so maybe I'm silly to even bring it up.  But it is just much more highly likely 
that a static method *may* examine local static state.  So the question is that 
if your method is defined on class C, then should the resulting function (F) 
really be an F3?

F<Class<C>, A1, A2, B>

I just want to get this static thing right overall before I move forward with 
it.  In this case, "right" may not mean purely mathematically right, but what 
is most useful, clear, concise, and non-constraining for a Java programmer 
using functional APIs.

Original comment by kandpwel...@gmail.com on 25 Jun 2012 at 6:11

[GoogleCodeExporter]

I commented on #31 in favor of F2 without C getting into the wrapped picture.

I can't think of a use case where I would want to depend dynamically on the 
static context (it is static). Even if some were found, my gut feeling is that 
restructuring / lifting statics to actual objects would be a better design.

Counterexamples welcome :)

Original comment by palotai....@gmail.com on 28 Jun 2012 at 1:34

[GoogleCodeExporter]

Maybe the scope of this issue could be extended to generate curried functions 
for all supported frameworks. That is, for a method A X::f(B, C) it would 
generate Fun<X, Fun<B, Fun<C, A>>>.

For FJ, wrapping up the curried F into FN can be done by users by appropriate 
FJ helpers.

Original comment by robinpal...@google.com on 7 May 2013 at 12:33