Hi Matt!

I changed the default arity with Eclipse help. After a quick glimpse everything 
looked fine in the api module. But in core module,  the packages oacf.adapter 
and oacf.composite  have classes like And and UnaryAnd, that could be updated 
to NullaryAnd and And, or NullaryAnd and UnaryAnd.

The {@link } in javadoc helped a lot too. 

But this change would affect a lot of other classes in core module (I think 
over 100 classes and test-classes). I think it would be easier to merge the 
generators branches without this change, so perhaps we could postpone it for 
now until we resolve FUNCTOR-14 [1] and merge the branches with the trunk. 

What do you think?

I've created FUNCTOR-24 [2] for this issue.

Thank you in advance,

[1] https://issues.apache.org/jira/browse/FUNCTOR-14
[2] https://issues.apache.org/jira/browse/FUNCTOR-24
 
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com


----- Original Message -----
> From: Matt Benson <gudnabr...@gmail.com>
> To: Commons Developers List <dev@commons.apache.org>
> Cc: 
> Sent: Monday, February 11, 2013 8:39 PM
> Subject: Re: [functor] Change default arity of Function, Predicate and 
> Procedure
> 
> Hi Bruno,
>   No objections here about the Arity interfaces.  I see that your master
> branch also contains changes to migrate Unary* to * and * to Nullary*.
> Personally I am satisfied to align with lambda/guava if noone else objects.
> 
> Thanks,
> Matt
> 
> 
> On Mon, Feb 11, 2013 at 4:25 PM, Bruno P. Kinoshita <
> brunodepau...@yahoo.com.br> wrote:
> 
>>  Hi Matt, all,
>> 
>>  I'm messing with [functor] in my GitHub mirror [1]. You can find the
>>  commits in the master branch [2].
>> 
>>  The Arity->Unary/Binary/Nullary interfaces look good. If there are no
>>  objections I would like to commit this change to the trunk in SVN.
>> 
>>  There are other changes that I'll omit in this commit, but will start 
> new
>>  threads here in the mailing list :o)
>> 
>>  Thank you in advance!
>> 
>>  [1] https://github.com/kinow/functor
>>  [2] https://github.com/kinow/functor/commits/master
>> 
>>  Bruno P. Kinoshita
>>  http://kinoshita.eti.br
>>  http://tupilabs.com
>> 
>> 
>>  >________________________________
>>  > From: Bruno P. Kinoshita <ki...@apache.org>
>>  >To: Commons Developers List <dev@commons.apache.org>; "
>>  gudnabr...@gmail.com" <gudnabr...@gmail.com>
>>  >Sent: Wednesday, January 30, 2013 3:58 PM
>>  >Subject: Re: [functor] Change default arity of Function, Predicate and
>>  Procedure
>>  >
>>  >I think it makes sense and is clear what is does.
>>  >
>>  >I thought in using {arity}Operation, but in Java 8 there are interfaces
>>  like BinaryOperator, and BinaryOperator extends BiFunction, so it would be
>>  confusing to users having something like interface BinaryFunction extends
>>  BinaryOperation in [functor].
>>  >
>>  >Bruno P. Kinoshita
>>  >http://kinoshita.eti.br
>>  >http://tupilabs.com
>>  >
>>  >
>>  >----- Original Message -----
>>  >> From: Matt Benson <gudnabr...@gmail.com>
>>  >> To: Bruno P. Kinoshita <brunodepau...@yahoo.com.br>
>>  >> Cc: Commons Developers List <dev@commons.apache.org>
>>  >> Sent: Wednesday, January 30, 2013 1:29 PM
>>  >> Subject: Re: [functor] Change default arity of Function, Predicate 
> and
>>  Procedure
>>  >>
>>  >> What about:
>>  >>
>>  >> Arity (Marker)
>>  >> |_Nullary extends Arity
>>  >> |_Unary<A> extends Arity
>>  >> |_Binary<L, R> extends Arity
>>  >>
>>  >> ?
>>  >>
>>  >> Matt
>>  >>
>>  >>
>>  >> On Tue, Jan 29, 2013 at 6:09 PM, Bruno P. Kinoshita <
>>  >> brunodepau...@yahoo.com.br> wrote:
>>  >>
>>  >>>  In Haskell you define your functions and its arity.
>>  >>>
>>  >>>  // nullary function
>>  >>>  a :: () => () -> String
>>  >>>  a = "Hello World"
>>  >>>
>>  >>>  // unary function
>>  >>>  b :: (Integral c) => c -: String
>>  >>>  b x = "Hello Integral"
>>  >>>
>>  >>>  I think in Clojure and Scala you can define the arity of the 
> function
>>  too.
>>  >>>
>>  >>>  For the users of [functor] I think it would be easier to 
> migrate their
>>  >>>  code to Java 8, or use it with Java 8, if both [functor] and 
> Java 8
>>  >>>  Function classes had similar behaviour. That would be 
> interesting
>>  >>>  especially if the lambda project provided a backport jar.
>>  >>>
>>  >>>  [functor] and lambda project provide 1 and 2 arities by 
> default, but
>>  >>>  lambda doesn't provide nullary interfaces (or at least I 
> couldn't
>>  >> find them
>>  >>>  in java.util.functions).
>>  >>>
>>  >>>  Cheers
>>  >>>
>>  >>>  Bruno P. Kinoshita
>>  >>>  http://kinoshita.eti.br
>>  >>>  http://tupilabs.com
>>  >>>
>>  >>>
>>  >>>  ----- Original Message -----
>>  >>>  > From: Matt Benson <gudnabr...@gmail.com>
>>  >>>  > To: Commons Developers List 
> <dev@commons.apache.org>; Bruno P.
>>  >>>  Kinoshita <brunodepau...@yahoo.com.br>
>>  >>>  > Cc:
>>  >>>  > Sent: Tuesday, January 29, 2013 8:57 PM
>>  >>>  > Subject: Re: [functor] Change default arity of Function, 
> Predicate
>>  and
>>  >>>  Procedure
>>  >>>  >
>>  >>>  > What about in pure functional languages e.g. Haskell?
>>  >>>  >
>>  >>>  > Matt
>>  >>>  >
>>  >>>  >
>>  >>>  > On Tue, Jan 29, 2013 at 4:55 PM, Bruno P. Kinoshita <
>>  >>>  > brunodepau...@yahoo.com.br> wrote:
>>  >>>  >
>>  >>>  >>  Hi all,
>>  >>>  >>
>>  >>>  >>  In Java 8 and Guava the default arity of a Function 
> is 1, but in
>>  >>>  [functor]
>>  >>>  >>  it is 0, IOW, in Java 8 and Guava a Function is by 
> default a
>>  >>>  UnaryFunction,
>>  >>>  >>  while in [functor] it is a NullaryFunction.
>>  >>>  >>
>>  >>>  >>  What do you guys think of changing the default 
> arity of Function,
>>  >>>  >>  Procedure and Predicate in [functor] to 1, rather 
> than 0?
>>  >>>  >>
>>  >>>  >>  Cheers
>>  >>>  >>
>>  >>>  >>  Bruno P. Kinoshita
>>  >>>  >>  http://kinoshita.eti.br
>>  >>>  >>  http://tupilabs.com
>>  >>>  >>
>>  >>>  >>
>>  >> 
> ---------------------------------------------------------------------
>>  >>>  >>  To unsubscribe, e-mail: 
> dev-unsubscr...@commons.apache.org
>>  >>>  >>  For additional commands, e-mail: 
> dev-h...@commons.apache.org
>>  >>>  >>
>>  >>>  >>
>>  >>>  >
>>  >>>
>>  >>
>>  >
>>  >---------------------------------------------------------------------
>>  >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>  >For additional commands, e-mail: dev-h...@commons.apache.org
>>  >
>>  >
>>  >
>>  >
>> 
>

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

Reply via email to