Hi Matt, 2013/2/12 Matt Benson <gudnabr...@gmail.com>
> Hi Benedikt, > So what you are pointing out is the "is a" vs. "has a" dichotomy? To an > extent, I see your point. I could argue that the semantics of the word > "implements" perhaps leaves a bit of so-called wiggle room on the is a/has > a subject. Now we are mixing things up. I was referring to the inheritance relationships between the interfaces. The java "implements" keyword is a different concept. Indeed, I'm not sure if it (or the notion of Interfaces) is part of the OO paradigm at all. There is an interesting paper about this topic (what are the core conecpts of object orientation?) [1]... Anyway the reason I'm bringing this rather academic topic up is, that I believe that a clear object-orient design will lead to a better (= easier to understand) API. People will work with the API. They will browse the type hierarchy to understand how things are tied together. This will lead to situations like: "okay, I have a BinaryFunction... what is a BinaryFuncation? Ah, it's a Binary... what is a Binary? A Binary seems to be an Arity... wait.. what?" Maybe I can make myself clearer by giving a less abstract example. Consider the following set of thinks: Cars, Trucks, Motorcycles. They all have wheels of some sort. How would you model this using Interfaces? I'm sure you wouldn't define an interface "Wheel" that is extended by Car, Truck and Motorcycle. Instead you would probably define "Vehicle" with a "getNumberOfWheels()" method and let Car, Truck and Motorcycle extend Vehicle. This is what I meant when I said "Arity is not a superset of functors". it is a property, like the number of Wheels is a property of all vehicles. Again, this is all very academic. If you see it fit to create Arity and have the different functors extend it, then do it :-) > This could devolve into a long discussion of the most > semantically correct place to use "implements Arity*" vs. "extends Arity*" > throughout the API, but the final result, IMO, is that the intent of any > given concrete class is clear enough, and Arity|Nullary|Unary|Binary|ad > infinitum seems more convenient than e.g. "SomethingThatHasArity", etc. > I agree! > > Does that make sense? > As I said, I think pragmatism should win over OO purism :) > > Matt > Benedikt [1] http://dl.acm.org/citation.cfm?id=1113040 > > > On Tue, Feb 12, 2013 at 7:29 AM, Benedikt Ritter <brit...@apache.org> > wrote: > > > Hi Guys, > > > > I've had a look at the github repo and let me say at first that I'm no > > expert in functional programming. So maybe what I'm talking is complete > > nonsense :) > > > > From what I learned about the concept of arity at wikipedia it seems that > > an arity is a property of a functor. > > One could say: "A binary functor has an arity of two" (right?!) > > > > In the github repo you introduced an inheritance relationship between > > functors and arity. > > This maybe a good thing to do from a pracmatic POV because all functors > > share the fact that say have an arity. > > > > From an object oriented POV inheritance is more then pure reuse. When > > defining an inheritance relationship between concept Super and concept > Sub > > we basically say "Every instance of Sub is also an instance of Super" or > > short "Every Sub is also a Super" > > > > Now coming back to functors you have introduced a relationship that says > > "Every BinaryFunction is a Binary and every Binary is an Arity". > > Keeping in mind that arity is only a property of a functor (rather than a > > superset) this seems strange (from an OO POV). > > But as I'm no expert on functional programming this maybe the right thing > > to do... :) > > > > just my 2 cents :) > > Benedikt > > > > > > > > 2013/2/11 Bruno P. Kinoshita <ki...@apache.org> > > > > > Hi Matt! > > > > > > Great! I'll commit these changes tomorrow if there are no objections. > > > > > > Thanks! > > > > > > 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 > > > > > > > > > > > > -- > > http://people.apache.org/~britter/ > > http://www.systemoutprintln.de/ > > http://twitter.com/BenediktRitter > > http://github.com/britter > > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
