Conditional methods "for free"

[Tomas Mikula]

Thank you for your explanation.

Tomas

On Tue, Dec 16, 2014 at 12:22 PM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> This is indeed a clever way to restrict applicability of certain methods to
> specific receivers. However, applicability is only half of the story here;
> the other half is membership. In your proposed solution, 'or' will be a
> member of Optional - regardless of the parameterization of the generic
> class. It seems likely that the feature we are after (not saying we have yet
> arrived to a full solution here) will also restrict membership - i.e. 'or'
> will simply not exist on an Optional<String> (and then applicability would
> of course follow). When  migrating legacy, erasure-based code, it is in fact
> fairly common to end up with cases in which existing methods
> (Collection.remove(Object) anyone?) no longer make sense in a fully any-fied
> world - and it is likely we will need a way that to say that those method
> are only members of certain receivers but not others.
>
> That said, stay tuned, as you'll soon hear more about this ;-)
>
> Maurizio
>
>
> On 16/12/14 02:41, Tomas Mikula wrote:
>>
>> On Sep 30, 2014, at 8:10 AM, Simon Ochsenreither <simon at
>> ochsenreither.de> wrote:
>>
>>>    There was a short mention of "conditional methods", e.g. enabling
>>>    methods only for a subset of some generic type.
>>
>> I don't know where conditional methods were mentioned and what their
>> current state is (any links?), but here is an idea how to get
>> conditional methods "for free" on top of two other (missing) features,
>> which would both be useful independently in their own right.
>>
>> The first feature is lower bounds on type parameters, i.e. <U super T>, as
>> in
>>
>>      class Optional<T> {
>>          public <U super T> Optional<U> or(Optional<? extends U> other);
>>      }
>>
>> The other one is to allow multiple type paramater bounds, even if one
>> of the bounds is itself a type variable. That is, allow bounds like <U
>> extends T & Foo> or <U extends Foo super T>.
>>
>> I have no idea how technically feasible these features are, but I have
>> encountered use cases for both of them.
>>
>> Once we have lower bounds and multiple bounds, we can express
>> conditional methods like this:
>>
>>      class Optional<T> {
>>          default <I extends Integer super T> int getAsInt() {
>>              I value = get();
>>              return value.intValue();
>>          }
>>      }
>>
>> Valid substitute for I exists only when T extends Integer, thus the
>> getAsInt() method can effectively be invoked only on
>> Optional<Integer>.
>>
>> Regards,
>> Tomas
>
>