On 14 February 2013 09:13, Jörg Schaible <joerg.schai...@scalaris.com> wrote:
> Benedikt Ritter wrote:
>
>> Hi Matt,
>>
>>
>> 2013/2/13 Matt Benson <gudnabr...@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-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
