Hi all, This thread started after I received feedback about [functor] from a FP programmer with knowledge in Haskell. Among his observations, was that Functors in Haskell have a different meaning and using Functors as function objects can mislead programmers from Haskell, scalaz and other functional programming languages.
However, in C++ a Functor has a meaning similar to [functor] Functor (pun inteded :-). In the beginning I liked the idea to replace it by the Arity interface, but after Benedikt's comments, and thinking from a FP programmer coming from Haskell, or even from other non pure FP languages like Python or Perl, I think it may cause some confusion too. So between Functor and Arity I would now prefer Functor. But there's a third option, that I want to experiment in my GitHub repo too. Use the Function interface as the superinterface in [functor]. This was suggested to me by the same guy that noticed the use of Functors with different meaning. I invited him to join us here in the mailing list, so hopefully he will chime in later. Basically, we would have: public interface Function<A, B> public interface Predicate<A> extends Function<A, Boolean> public interface Procedure<A> extends Function<A, Void> I have the feeling this could be useful with function currying and function folding. I'll experiment with while playing with the adapter and composite packages. But I think maybe the Function interface could be indeed used as the superinterface, replacing the Functor concept in [functor]. What do you guys think? Thank you in advance! ps: in Java 8, the @FunctionalInterface does not guarantee the arity of classes, but raises compile time errors if you define an invalid functional interface (like one interface with two abstract public methods). This applies to [functor] interfaces, any subclasses of Functor can be annotated with @FunctionalInterface and used with lambdas :) Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com >________________________________ > From: Benedikt Ritter <benerit...@gmail.com> >To: Commons Developers List <dev@commons.apache.org> >Sent: Friday, February 15, 2013 6:54 AM >Subject: Re: [functor] Change default arity of Function, Predicate and >Procedure > >2013/2/14 Oliver Heger <oliver.he...@oliver-heger.de> > >> Am 14.02.2013 16:51, schrieb Matt Benson: >> >> I would say that certainly one would often want to create an API like >>> you've described. What I am reluctant not to support is: >>> >>> class Foo { >>> static void add(Argumented<Binary<? extends CharSequence, ? extends >>> CharSequence>> functor); >>> } >>> >>> Foo.add(new BinaryFunction<String, String, String>() {}); >>> Foo.add(new BinaryProcedure<String, StringBuffer>() {}); >>> Foo.add(new BinaryPredicate<String, StringBuilder>() {}); >>> >>> The arguments are alike in their "argumentedness" while having different >>> functional interfaces. Convince me this can never be useful, and we can >>> drop the whole thing ;P >>> >>> Matt >>> >> >> Scala seems to use a similar approach: There are traits (a trait is >> something like a more advanced interface in Java) like Function1, >> Function2, ... with type parameters for the argument types and the result >> type. >> >> The nice thing in Scala is that its syntax allows you to write function >> literals in a pretty comprehensive form. The compiler maps this >> automatically to the corresponding FunctionX trait. >> >> Oliver > > >I'd say, let's try Matts proposal out and see how it feels. WDYT? > >Benedikt > > >> >> >> >>> >>> On Thu, Feb 14, 2013 at 8:55 AM, Jörg Schaible >>> <joerg.schai...@scalaris.com>**wrote: >>> >>> Hi Matt, >>>> >>>> Matt Benson wrote: >>>> >>>> Once again, an enum wouldn't readily be able to contribute to your >>>>> functor's being able to participate in some method by type signature; >>>>> i.e., I want to support the use case of: >>>>> >>>>> add(Argumented<Binary> somethingThatTakesTwoArguments**); >>>>> >>>>> Maybe this isn't a worthwhile goal, but so far I don't see anything else >>>>> that accomplishes this. >>>>> >>>> >>>> In any case, I wonder if we really want to support type safety for the >>>> argument *types* themselves. >>>> >>>> [snip] >>>> >>>> >>>>>>>>> interface Arity { >>>>>>>>> } >>>>>>>>> >>>>>>>>> interface Argumented<A extends Arity> { >>>>>>>>> } >>>>>>>>> >>>>>>>>> interface Unary<A> extends Arity { >>>>>>>>> } >>>>>>>>> >>>>>>>>> interface UnaryFunction<A, T> extends Argumented<Unary<A>> { >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> This is more complicated then having the functors extend Arity, but >>>>>>>> >>>>>>> it >>>> >>>>> makes better use of inheritance from an OO POV I think. >>>>>>>> >>>>>>>> Just to make sure I understand correctly: If I had an UnaryFunction >>>>>>>> that take a Boolean argument and return an Integer I would model this >>>>>>>> as: class MyFunction implements UnaryFunction<Boolean, Integer>, >>>>>>>> right? >>>>>>>> >>>>>>> >>>> class Foo { >>>> static CharSequence add(UnaryFunction<? extends CharSequence, ? extends >>>> CharSequence> f); >>>> } >>>> >>>> Foo.add(new UnaryFunction<String, String>(){}); >>>> Foo.add(new UnaryFunction<StringBuilder, String>(){}); >>>> Foo.add(new UnaryFunction<StringBuilder, StringBuilder>(){}); >>>> >>>> >>>> This could get really nasty to use. >>>> >>>> - Jörg >>>> >>>> >>>> ------------------------------**------------------------------** >>>> --------- >>>> To unsubscribe, e-mail: >>>> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>>> >>> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> dev-unsubscribe@commons.**apache.org<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
