commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [functor] Change default arity of Function, Predicate and Procedure
Date Thu, 14 Feb 2013 20:49:37 GMT
Am 14.02.2013 16:51, schrieb Matt Benson:
> I would say that certainly one would often want to create an API like
> you've described.  What I am reluctant not to support is:
>
> class Foo {
>    static void add(Argumented<Binary<? extends CharSequence, ? extends
> CharSequence>> functor);
> }
>
> Foo.add(new BinaryFunction<String, String, String>() {});
> Foo.add(new BinaryProcedure<String, StringBuffer>() {});
> Foo.add(new BinaryPredicate<String, StringBuilder>() {});
>
> The arguments are alike in their "argumentedness" while having different
> functional interfaces.  Convince me this can never be useful, and we can
> drop the whole thing ;P
>
> Matt

Scala seems to use a similar approach: There are traits (a trait is 
something like a more advanced interface in Java) like Function1, 
Function2, ... with type parameters for the argument types and the 
result type.

The nice thing in Scala is that its syntax allows you to write function 
literals in a pretty comprehensive form. The compiler maps this 
automatically to the corresponding FunctionX trait.

Oliver

>
>
> On Thu, Feb 14, 2013 at 8:55 AM, Jörg Schaible
> <Joerg.Schaible@scalaris.com>wrote:
>
>> Hi Matt,
>>
>> Matt Benson wrote:
>>
>>> 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.
>>
>> In any case, I wonder if we really want to support type safety for the
>> argument *types* themselves.
>>
>> [snip]
>>
>>>>>>>
>>>>>>> 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?
>>
>>   class Foo {
>>   static CharSequence add(UnaryFunction<? extends CharSequence, ? extends
>> CharSequence> f);
>>   }
>>
>>   Foo.add(new UnaryFunction<String, String>(){});
>>   Foo.add(new UnaryFunction<StringBuilder, String>(){});
>>   Foo.add(new UnaryFunction<StringBuilder, StringBuilder>(){});
>>
>>
>> This could get really nasty to use.
>>
>> - 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