2013/2/14 Oliver Heger <oliver.he...@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.schai...@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-unsubscr...@commons.apache.org>
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail:
> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org>
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
