commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [functor] Change default arity of Function, Predicate and Procedure
Date Thu, 14 Feb 2013 11:15:46 GMT
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
View raw message