commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [functor] Change default arity of Function, Predicate and Procedure
Date Thu, 14 Feb 2013 13:38:37 GMT
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.

Matt


On Thu, Feb 14, 2013 at 5:15 AM, sebb <sebbaz@gmail.com> wrote:

> On 14 February 2013 09:13, Jörg Schaible <Joerg.Schaible@scalaris.com>
> wrote:
> > Benedikt Ritter wrote:
> >
> >> Hi Matt,
> >>
> >>
> >> 2013/2/13 Matt Benson <gudnabrsam@gmail.com>
> >>
> >>> TBH, I can't recall what the argument was against "Functor" either; I
> >>> think it had something to do with potentially confusing users of other
> >>> libraries?
> >>>
> >>> Functor
> >>> |_NullaryFunctor
> >>> |_UnaryFunctor
> >>> |_BinaryFunctor
> >>>
> >>> *is* the current state.  :)  Now, when I woke up this morning I did so
> >>> with another concept floating around in my brain (it may be crazy, or
> not
> >>> work):
> >>>
> >>> 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?
> >>
> >> May this is obviouse and I just don't get it, but why do you need to
> >> define *ary Interfaces? Wouldn't it be easier to just define:
> >>
> >> interface Argumented {
> >>   int getArity()
> >> }
> >>
> >> You would lose the information which types can be passed to the functor.
> >> OTOH you don't have to define a new interface for every possible arity.
> >
> > You also lose the implicit compile-time check for the arity itself:
> >
> > class MyFunction<Boolean,Integer> extends Argumented {
> >    int getArity() { return 5; } // blunt lie
> > ...
> > }
>
> Would an enum help here?
>
> > - Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message