My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 55: Support wrapping multi-parameter methods to functionaljava FN functions.
1 person starred this issue and may be notified of changes. Back to list
Status:  New
Owner:  ----


 
Reported by palotai....@gmail.com, Jun 6, 2012
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>
Jun 6, 2012
Project Member #1 kandpwel...@gmail.com
changing from defect to enhancement request
Labels: -Type-Defect Type-Enhancement
Jun 25, 2012
Project Member #2 kandpwel...@gmail.com
Related to this proposal is Issue 31.  A question I asked over there (https://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.
Jun 28, 2012
#3 palotai....@gmail.com
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 :)
May 7, 2013
#4 robinpal...@google.com
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.

Powered by Google Project Hosting