Benedikt Ritter wrote:
> Hi Matt,
>
>
> 2013/2/13 Matt Benson <[email protected]>
>
>> 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
...
}
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
