commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <benerit...@gmail.com>
Subject Re: [functor] Change default arity of Function, Predicate and Procedure
Date Fri, 15 Feb 2013 08:54:06 GMT
2013/2/14 Oliver Heger <oliver.heger@oliver-heger.de>

> 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


I'd say, let's try Matts proposal out and see how it feels. WDYT?

Benedikt


>
>
>
>>
>> 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<dev-unsubscribe@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<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