Sounds reasonable, I agree.
Matt
On Tue, Feb 12, 2013 at 3:49 PM, Bruno P. Kinoshita <ki...@apache.org>wrote:
> 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
> >> >
> >> >
> >> >
> >> >
> >>
> >
>
