looking for FAQ on interconversion of IntFoo and Foo<Integer>
Ali Ebrahimi
ali.ebrahimi1781 at gmail.com
Wed Apr 17 07:08:29 PDT 2013
Hi,
What is problem when IntSupplier inherits from Supplier?
what is result for System.out.println(gen(() -> 3)); ?
Ali Ebrahimi
On Wed, Apr 17, 2013 at 5:53 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> On 04/17/2013 10:08 AM, Ali Ebrahimi wrote:
>
>> Hi,
>> does not IntSupplier specialize Supplier? if yes, should not IntSupplier
>> wins over Supplier. what is most specific candidate?
>>
>> Ali Ebrahimi
>>
>
> yes exactly, and it wins without IntSupplier having to extends Supplier.
>
> Let's take an example:
> public static <T> T gen(Supplier<? extends T> supplier) {
> System.out.println("generic");
> return supplier.get();
> }
>
> public static int gen(IntSupplier supplier) {
> System.out.println("**specialized");
> return supplier.getAsInt();
> }
>
> public static void main(String[] args) {
> System.out.println(gen(() -> 3));
> }
>
> it will print "specialized" even if IntSupplier doesn't inherits from
> Supplier,
>
> gen is called with () -> int, so gen(Supplier) and gen(IntSupplier) can be
> called,
> neither is more specific than the other because there is not subtyping
> relationship between Supplier and IntSupplier
> but because () -> 3 is a lambda and Supplier and IntSupplier are function
> interfaces,
> the compiler will see Supplier and IntSupplier as structural type,
> i.e. the compiler will see Supplier as <T> () -> T and IntSupplier as ()
> -> int,
> and because () -> int is more specific, gen(IntSupplier) will be chosen
> are most specific method.
>
> cheers,
> Rémi
>
>
>
>>
>> On Tue, Apr 16, 2013 at 12:57 PM, Remi Forax <forax at univ-mlv.fr <mailto:
>> forax at univ-mlv.fr>> wrote:
>>
>> On 04/16/2013 09:01 AM, John Rose wrote:
>> > Where is the standard place to find the design discussion for
>> primitive-type specializations of the new interfaces (functions,
>> producers, consumers, optionals...)?
>> >
>> > In particular, will users be able to ignore higher-order
>> functions of unboxed values and later adjust code locally for
>> efficiency?
>> >
>> > If so, are there conversion operators that correspond to
>> auto-box and auto-unbox of non-functional, which can be used to
>> make adjustments at the boundaries?
>>
>> From the compiler point of view, in a lambda conversion Integer as is
>> not a boxed int,
>> so there is no such auto-boxing. Said differently a Stream of Integers
>> and a Stream of ints are not the same object.
>>
>> >
>> > Finally (and this is what prompted me to ask) why not make
>> IntSupplier or OptionalInt be sub-interfaces of the
>> reference-bearing ones, with autoboxing around the edges (see below)?
>>
>> At some point in the past, IntSupplier was a subtype of Supplier
>> but it
>> doesn't play well with type inference
>> and method resolution in the compiler
>> Supplier or IntSupplier because they are functional interface are seen
>> by the compiler as structural types
>> and mixing structural types and classical subtyping relationship has
>> some hairy interactions.
>>
>> >
>> > Since this is probably a rehash of past discussions, I'm looking
>> to be pointed at some sort of Email thread or even (!) a wiki page.
>> >
>> > Best,
>> > — John
>>
>> cheers,
>> Rémi
>>
>> >
>> > P.S. It looks like this sort of stuff was in the repo at first
>> and then was yanked recently.
>> >
>> > diff --git
>> a/src/share/classes/java/util/**function/IntSupplier.java
>> b/src/share/classes/java/util/**function/IntSupplier.java
>> > --- a/src/share/classes/java/util/**function/IntSupplier.java
>> > +++ b/src/share/classes/java/util/**function/IntSupplier.java
>> > @@ -32,7 +32,12 @@
>> > * @since 1.8
>> > */
>> > @FunctionalInterface
>> > -public interface IntSupplier {
>> > +public interface IntSupplier
>> > + extends Supplier<Integer>
>> > +{
>> > + /** Returns the result of {@code getAsInt}, boxed. */
>> > + // in my dreams, this would allows IntSupplier to convert
>> to Supplier<Integer>
>> > + public default Integer get() { return getAsInt(); }
>> >
>> > /**
>> > * Returns an {@code int} value.
>> >
>> >
>>
>>
>>
>>
>
More information about the lambda-dev
mailing list