https://kotlinlang.org logo
Join Slack
Powered by
Hmm. I have a class, e. g. `class Something<X :...
# announcements
m
Hmm. I have a class, e. g. 
class Something<X : Serializable>
. In Java, within a class with unbound 
T
type parameter, 
public void do(Something<T> something)
is an error (since only 
Something<T & Serializable>
can exist in this context), but 
Something<? extends T>
is OK. In Kotlin, both 
Something<T>
and 
Something<out T>
are errors. Is it by Kotlin design? Or a Java bug? 🙃
b
@miha-x64 can you paste the entire class somewhere? Or a relevant example in the try Kotlin page?
m
Also:
Copy code
public class ConvertMeAndCry {
    public <X> ConvertMeAndCry(List<? extends X> list) { }
}
b
fun <T : Serializable> x(someting:Something<T>) {
m
@bjartek no, in Java I use class's T in method.
b
@miha-x64 ok. Hard to help properly when I do not have the entire context.
🤔 1
a
i'd say java is wrong there. in your 
x(Something<? extends T> something)
your T can be any class, even one that is not 
Serializable
the 
T
of 
x()
has nothing to do with the 
T
of 
Something
m
@Andreas Sinz before you pass an instance of 
Something<out T>
into a function, you must obtain it somehow and here its 
out Serializable
bound will work. And my class don’t want to know anything about it, just 
out T
. I don’t think Java will allow a mistake here.
a
@miha-x64 yeah, java doesn't allow it. the only problem I see with this code is that the upper bound is implicit in your 
x()
@orangy ^^
m
@Andreas Sinz I don’t think Orangy will be very happy to be pinged. 🤔
o
I’m used to it 🙂 but please don’t expect that I can be summoned any time and help right away. When I can, I help.
I think @stanislav.erokhin could have an answer.
s
It isn’t java bug. Type 
Something<? extends T>
is correct type, because may be there is type 
C
which is subtype of 
T
and of 
Serializable
and 
Something<C>
is subtype of 
Something<? extends T>
. In kotlin such types (
Something<out T>
) forbidden for now by design but we have plans to allow them in future versions.
m
@stanislav.erokhin thank you for explanation. And why constructor type parameters are disallowed?
s
Because without them compiler code is much easier 🙂 Real reason is that we think that such conception is useless and can be replaced via invoke function inside companion object:
Copy code
class Foo<T> {
    companion object {
        operator fun <K, T> invoke(k: K, t: T): Foo<T> = Foo()
    }
}

fun main(args: Array<String>) {
    Foo<Int, String>(1, "")
    Foo(1, "")
}
m
@stanislav.erokhin oh, I see, thank you. I ask because of the real use-case: a class has two constructors, the first one can accept a parameter of type 
LiveList<? extends MDL>
, which is actually 
LiveList<? extends MDL & WithId>
, because of 
class LiveList<T extends WithId>
, and the second one does not mind 
WithId
and just requires 
List<? extends MDL>
. https://github.com/Miha-x64/LiveLists4GreenDAO/blob/master/greenLiveLists/src/main/java/net/aquadc/livelists/greendao/LiveAdapter.java#L31 https://github.com/Miha-x64/LiveLists4GreenDAO/blob/master/greenLiveLists/src/main/java/net/aquadc/livelists/greendao/LiveAdapter.java#L89
2 Views
Open in Slack
PreviousNext
Powered by